[asterisk-ss7] Error in t1_timeout (arg=0x8180078) at chan_ss7.c:765 makes asterisk crash

[Kristian Nielsen]

Kai Militzer <km at westend.com> writes:

> I made the changes suggested and changed the one line in chan_ss7.c to
>
> isup_send_rel(pvt, pvt->hangupcause);
>
> But my asterisk still crashed for a lot of simultaneous outgoing calls.

Yes, but this time it's another crash!

> #0  0x408622ac in t9_start (chan=0x0) at chan_ss7.c:903
> #1  0x4086664f in process_acm (pvt=0x817d7f0, inmsg=0xbd1ffa34)
>     at chan_ss7.c:2337
> #2  0x40865e5c in process_circuit_message (slink=0x40889600, 
> inmsg=0xbd1ffa34,

Hm, there's clearly a bug in that process_acm() function.

It's called with pvt->owner == NULL, which is perfectly possible,
happens for example if we place a call and then hang up quickly before
the ACM returns (our REL and the peer's ACM cross on the wire)

I haven't checked what Q.704 says, but it most likely says to ignore the
ACM. So there should probably be a check if we are in state ST_SENT_REL,
and in that case just ignore the message. I think Anders will sort that out.

For a quick fix, try moving the this line in process_acm():

  t9_start(chan);

down to after this code, which checks for a NULL chan:

  if(chan == NULL) {
    ast_log(LOG_NOTICE, "Missing chan pointer for CIC=%d, processing ACM?!?\n", pvt->cic);
    return;
  }

that should fix the crash, though I think the code is still not quite
right (ie. no need to reset the circuit in this case).

Would be great if you could try this change and send us the next crash!
BTW, nice problem reports with backtraces and everything ...

Incidentally, I wonder if you are making calls faster than a single E1
signalling time slot can handle? In any case it's very good that you
do, you've already found us two crashing bugs :-).

 - Kristian.