Hi,
we had got series of SER cores with failed assertion in t_retransmit_reply():
assert(t->uas.response.dst.send_sock);
Essential backtrace part:
#0 0x48167fc4 in kill () from /usr/lib/libc.so.4 #1 0x481a993e in abort () from /usr/lib/libc.so.4 #2 0x481858d3 in __assert () from /usr/lib/libc.so.4 #3 0x48281da3 in t_retransmit_reply () from /usr/local/lib/ser/modules/tm.so #4 0x48277433 in t_newtran () from /usr/local/lib/ser/modules/tm.so
This place from ser.cfg:
if (!t_newtran()) { sl_send_reply("500", "could not create transaction"); break; };
response.dst.send_sock is filled in init_rb(), which is called from t_newtran(). t_newtran() has the following:
=== cut === UNLOCK_HASH(p_msg->hash_index); /* now, when the transaction state exists, check if there is a meaningful Via and calculate it; better do it now than later: state is established so that subsequent retransmissions will be absorbed and will not possibly block during Via DNS resolution; doing it later would only burn more CPU as if there is an error, we cannot relay later whatever comes out of the the transaction */ if (!init_rb( &T->uas.response, p_msg)) { LOG(L_ERR, "ERROR: t_newtran: unresolvable via1\n"); put_on_wait( T ); t_unref(p_msg); return E_BAD_VIA; }
return 1; === end cut ===
Does there race condition between UNLOCK_HASH(), init_rb() and parallel t_newtran() from another SER process exist?
Details: FreeBSD 4.10, SER 0.9.3 (with PortaOne additions, but not essential for the question).