[asterisk-dev] asterisk 1.2.14 segfault

Paul Cadach paul at odt.east.telecom.kz
Thu Feb 1 13:08:27 MST 2007


Don't forget that newest PCs are not so stable as oldest because their chips 
made by much smaller elements (transistors, etc.) so it is very sensitive to 
external condition (sun rays, etc.). So, be ready to rarely have 
unidentified problems.

In the code you shown all is easy as possible - we failed on access to 
structure member. Because pointer to structure isn't NULL (and isn't changes 
to NULL in q931_hangup()), so there are 3 cases:
1) you have WRONG pointer (which points on segment/page boundary and memory 
part where member "cause" located is outside of valid memory pages);
2) you got fauit in another thread but something pointed you to wrong 
thread;
3) you hit some uncontrollable condition (like sunrays, etc.).

To verify 1), just do "print *c" in GDB and check data in all fields for 
validity. It is not so complex. If all is fine, than you hit 2) or 3).
Case 2) is much harder to study, and log files analyzis is the single way to 
figure out something wrong then check if it had side-effects caused your PRI 
code to crash.


WBR,
Paul.
----- Original Message ----- 
From: "Anton" <anton.vazir at gmail.com>
To: <asterisk-dev at lists.digium.com>
Sent: Thursday, February 01, 2007 2:36 AM
Subject: Re: [asterisk-dev] asterisk 1.2.14 segfault


> The system had uptime over 1 month with moderate load (~100K
> min/month), I'm sure that I've actually have rebuilt the
> system.
>
> On 31 January 2007 21:04, Matthew Fredrickson wrote:
>> It sounds like an API mismatch.  Make sure you actually
>> rebuilt asterisk/chan_zap after you upgraded libpri and
>> zaptel.
>>
>> Matthew Fredrickson
>>
>> On Jan 29, 2007, at 4:43 AM, Anton wrote:
>> > I've got a segfault of the 1.2.14 zaptel 1.2.12 libpri
>> > 1.2.3
>> >
>> >
>> > Loaded symbols for /lib/tls/libnss_dns.so.2
>> > #0  0xb761a11e in q931_hangup (pri=0x8231eb8,
>> > c=0x83705e8, cause=16) at q931.c:2879
>> > 2879            if (c->cause ==
>> > PRI_CAUSE_MANDATORY_IE_MISSING) (gdb) bt
>> > #0  0xb761a11e in q931_hangup (pri=0x8231eb8,
>> > c=0x83705e8, cause=16) at q931.c:2879
>> > #1  0xb761012f in pri_hangup (pri=0x8231eb8,
>> > call=0x83705e8, cause=16) at pri.c:551
>> > #2  0xb7657aab in pri_dchannel (vpri=0xb766bac8) at
>> > chan_zap.c:8256 #3  0xb7f64b63 in start_thread () from
>> > /lib/tls/libpthread.so.0 #4  0xb7e5f18a in clone ()
>> > from /lib/tls/libc.so.6 (gdb)
>> > _______________________________________________
>> > --Bandwidth and Colocation provided by Easynews.com --
>> >
>> > asterisk-dev mailing list
>> > To UNSUBSCRIBE or update options visit:
>> >
>> > http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 



More information about the asterisk-dev mailing list