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?
regards
--
Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
