Hi Michał, > On Jan 17, 2020, at 6:37 AM, Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> wrote: > > Hi Brian, > > On 01/17, Gix, Brian wrote: >>> Hm. I can't seem to wrap my head around this backtrace. Do you maybe >>> have a reproduction path? >> >> The backtrace doesn’t really show what has gone wrong very well, >> because what has happened is a heap corruption. The seg fault occurs >> during a memory alloc sometime later. >> >> The physics of the problem, is best shown by local config client >> requesting segmented composition data from a local config server. The >> one request, all response segments, the return seg ACKs all happen on >> the same C calling stack which gets *very* deep, and steps off the >> end, since nothing goes OTA. It does *not* happen during OTA >> operations because each discrete packet starts from a fresh C calling >> stack from main(). > > Yeah, I got that part - l_idle unwinds the stack so that everything > starts from the beginning, it'a pretty standard technique for main > loops. > > What I couldn't find is the exact place where send_msg_pkt recurses, but > I think I've found it now, e.g. in this call chain: > > send_msg_pkt > net_rx > packet_received > seg_rxed > send_net_ack > mesh_net_transport_send > send_msg_pkt <- here > > In the end: the patch is fine, but maybe change the commit log and/or a > comment, since, as you remarked, the backtrace doesn't explain much? The commit message is our standard explanation when a bug has caused a crash/seg fault, so that others suffering the same fate can match the problem with the fix. It isn’t really intended to be all info required to debug the problem yourself.
