On 25/02/2019 12.34, Daniel-Constantin Mierla wrote:
Hello,
that's strange, but a while ago someone else reported an issue with same backtrace.
So the crash happens at the last line in the next snippet from reply_received() function in the tm module:
uac=&t->uac[branch]; LM_DBG("org. status uas=%d, uac[%d]=%d local=%d is_invite=%d)\n", t->uas.status, branch, uac->last_received, is_local(t), is_invite(t)); last_uac_status=uac->last_received;
The backtrace and info locals say that uac is null (0x0). According to my knowledge, the address of a field in a structure cannot be null and uac is set to &t->uac[branch]. Moreover, uac->last_received is printed in the LM_DBG() above the line of crash, if uac was 0x0, the crash should have happened there.
t->uac is a pointer to an array, not a static array contained in the struct. So, if t->uac was null, then &t->uac[branch] would also yield null if branch was zero. (For a non-zero branch, it would yield a pointer to somewhere just past null. &t->uac[branch] is the same as t->uac + branch.)
As for LM_DBG, I'm not too familiar with the logging macros, but if they're defined in such a way to check the log level first and then skip calling the actual logging function if the log level is too low, then the LM_DBG arguments would never be evaluated and so no null dereference would occur there.
I was debugging a similar core dump just the other day, although in a different location. That one was in t_should_relay_response(), line 1282, and also had Trans->uac == null. The strange part about this one was that according to gdb, Trans->uac was valid:
#0 0x00007f3f11d5b5e8 in t_should_relay_response (Trans=Trans@entry=0x7f3e14a551f8, new_code=new_code@entry=200, branch=branch@entry=0, should_store=should_store@entry=0x7fffb0353408, should_relay=should_relay@entry=0x7fffb0353404, cancel_data=cancel_data@entry=0x7fffb0353670, reply=0x7f3f160aa6e8) at t_reply.c:1282 1282 in t_reply.c (gdb) p Trans->uac[branch].last_received $11 = 0
even though the asm instruction definitely was a null dereference into ->uac:
0x00007f3f11d5b5de <+718>: add 0x170(%rbx),%r8 => 0x00007f3f11d5b5e8 <+728>: mov 0x190(%r8),%eax (gdb) p $r8 $2 = 0
%rbx had Trans and so %r8 had Trans->uac. At this point, %8 == Trans->uac == null, even though:
(gdb) p (long int) Trans->uac $18 = 139904611079176
Investigating further, we found that Trans resided in shared memory and so we (tentatively) concluded that this looks to be a race condition with another process overwriting the Trans shm. First Trans->uac was null and got assigned to %r8, then another process changed it to something valid in shm, then the segfault happened through %r8. We didn't have a chance to investigate further and I can't say for sure if these two crashes are related.
Cheers