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

Goke Aruna goksie at gmail.com
Sun Apr 30 21:46:43 MST 2006


I am sorry for double post I just read the full bt

#0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
765       isup_send_rel(pvt, pvt->hangupcause);
(gdb) bt full
#0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
        pvt = (struct ss7_chan *) 0x82f11c0
        __PRETTY_FUNCTION__ = "t1_timeout"
#1  0x08056668 in ast_sched_runq (con=0x832a9c8) at sched.c:373
        tv = Unhandled dwarf expression opcode 0x93
(gdb) bt
#0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
#1  0x08056668 in ast_sched_runq (con=0x832a9c8) at sched.c:373
#2  0xf6a97d16 in monitor_main (data=0x0) at chan_ss7.c:3413
#3  0x00c161d5 in start_thread () from /lib/tls/libpthread.so.0
#4  0x00a972da in clone () from /lib/tls/libc.so.6

goksie

On 5/1/06, Goke Aruna <goksie at gmail.com> wrote:
>
> Thank you,
>
> the bt is here:
>
>
> #0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
> 765       isup_send_rel(pvt, pvt->hangupcause);
> (gdb) bt
>
> #0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
> #1  0x08056668 in ast_sched_runq (con=0x832a9c8) at sched.c:373
> #2  0xf6a97d16 in monitor_main (data=0x0) at chan_ss7.c:3413
> #3  0x00c161d5 in start_thread () from /lib/tls/libpthread.so.0
> #4  0x00a972da in clone () from /lib/tls/libc.so.6
>
> goksie
>
>
> On 4/30/06, Anton <anton.vazir at gmail.com> wrote:
> >
> > Could you invoke a
> > "backtrace" command in gdb to see how it got there.
> >
> > On 30 April 2006 00:04, Goke Aruna wrote:
> > > my ss7 crashed with the following error taking from the
> > > core dump. the crash is noticed after the call reached a
> > > peak of 34 calls... and fter then I made max inbound on
> > > oh323 to 29 so that it will not go to the second ss7 and
> > > I disable the link and phyically removed it. my provider
> > > too get it blocked.
> > >
> > > however, all the changes made by Kai and Kristian were
> > > followed.
> > >
> > > I am running asterisk-1.2.5, chan_ss7-0.8.3 with zaptel
> > > 1.2.4
> > >
> > > I have the follwoing from my dump
> > > Reading symbols from /lib/libgcc_s.so.1...done.
> > > Loaded symbols for /lib/libgcc_s.so.1
> > > #0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at
> > > chan_ss7.c:765 765       isup_send_rel(pvt,
> > > pvt->hangupcause);
> > >
> > > I have the core dump and the ss7 dump and I will be glad
> > > if someone can help.
> > >
> > > the extract from my chan_ss7.c are as below
> > >
> > > ## FOR THE isup_send_rel(pvt, pvt->hangupcause);######
> > >
> > > static int start_timer(int msec, int (*cb)(void *), void
> > > *data) { int id = ast_sched_add(monitor_sched, msec, cb,
> > > data); if(msec < MONITOR_FREQ) {
> > >     wakeup_monitor();
> > >   }
> > >   return id;
> > > }
> > >
> > > static int t1_timeout(void *arg) {
> > >   struct ss7_chan *pvt = arg;
> > >
> > >   ast_log(LOG_NOTICE, "T1 timeout (waiting for RLC)
> > > CIC=%d.\n", pvt->cic); isup_send_rel(pvt,
> > > pvt->hangupcause);
> > >   //isup_send_rel(pvt, pvt->owner->hangupcause);
> > >   return 1;                     /* Run us again the next
> > > period */ }
> > >
> > > /* This should be called with pvt->lock held. */
> > > static void t1_clear(struct ss7_chan *pvt) {
> > >   if(pvt->t1 != -1) {
> > >     ast_sched_del(monitor_sched, pvt->t1);
> > >     pvt->t1 = -1;
> > >   }
> > > }
> > >
> > > /* This should be called with pvt->lock held. */
> > > static void t1_start(struct ss7_chan *pvt) {
> > >   t1_clear(pvt);
> > >   pvt->t1 = start_timer(30000, t1_timeout, pvt);
> > > }
> > >
> > >
> > >
> > > ### FOR t9_start(chan) #########
> > > if(pvt->state != ST_SENT_IAM) {
> > >     ast_log(LOG_NOTICE, "Got ACM message, but sent no
> > > IAM, on CIC=%d?!?", pvt->cic);
> > >     /* Q.764 (2.9.5.1 f) error handling for the spurious
> > > ACM. */ if(pvt->state == ST_IDLE)
> > >       reset_circuit(pvt);
> > >     return;
> > >   }
> > >
> > >   if(chan == NULL) {
> > >     ast_log(LOG_NOTICE, "Missing chan pointer for CIC=%d,
> > > processing ACM?!?\n", pvt->cic);
> > >     return;
> > >   }
> > >
> > >   t9_start(chan);
> > >
> > >   /* Q.764 (2.1.4.6 a): Alert if called_party_status is
> > > "subscriber free". */
> > >   if(inmsg-> acm.back_ind.called_party_status == 1) {
> > >     ast_queue_frame(chan, &ring_frame);
> > >   }
> > >
> > >
> > > Goksie
> > >
> > > On 3/22/06, Kai Militzer <km at westend.com > wrote:
> > > > Hello Kristian and rest,
> > > >
> > > > Kristian Nielsen wrote:
> > > > > 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!
> > > >
> > > > That helped. I wasn't able to get it crashing again,
> > > > but I'll try to find something else ... ;)
> > > >
> > > > > BTW, nice problem reports with backtraces and
> > > > > everything ...
> > > >
> > > > You are welcome ... I want a usable version of chan_ss7
> > > > at the end of june because I need to go into production
> > > > then ;)
> > > >
> > > > > 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 :-).
> > > >
> > > > What I do to test is the following:
> > > >
> > > > I have an asterisk that dials out via iax to the
> > > > asterisk with the ss7 which then dials out via ss7 to
> > > > another external ss7 gateway which then connects to
> > > > another asterisk that starts an echo application. I
> > > > start this call with a .call file (or better: 60 of
> > > > them) that I copy into the spool dir. When the call is
> > > > connected, I start playback of a MP3 file via the
> > > > dialplan. Because of this I have 60 parallel calls
> > > > starting at once. This is not what you will have in
> > > > real life, but it helps to find bugs and gives me an
> > > > idea of what the max load is that my system can handle.
> > > >
> > > > If you have any other ideas how/what else I can test, I
> > > > am happy to give it a try.
> > > >
> > > > Best regards,
> > > > Kai
> > > >
> > > > --
> > > > Kai Militzer                 WESTEND GmbH  |
> > > > Internet-Business-Provider Technik
> > > > CISCO Systems Partner - Authorized Reseller Lütticher
> > > > Straße 10      Tel 0241/701333-14 km at westend.com
> > > >        D-52064 Aachen              Fax 0241/911879
> > > >
> > > > _______________________________________________
> > > > --Bandwidth and Colocation provided by Easynews.com --
> > > >
> > > > asterisk-ss7 mailing list
> > > > To UNSUBSCRIBE or update options visit:
> > > >
> > > > http://lists.digium.com/mailman/listinfo/asterisk-ss7
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-ss7 mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-ss7
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20060430/abc86c74/attachment-0001.htm


More information about the asterisk-ss7 mailing list