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@xxxxxxxxxxx> 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@xxxxxxxxxxx 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20060429/c1595b67/attachment.htm
|