[Home]

Summary:ASTERISK-04704: [patch] astrisk crashes with zaptel-pri and overlapdial=yes
Reporter:thaeger (thaeger)Labels:
Date Opened:2005-07-27 09:40:02Date Closed:2005-08-26 12:34:04
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt.txt
( 1) dsp.c.patch
Description:Hi,

we had two customers with asterisk crashes today.
They have reported crashes if an incoming call comes in with overlapdial.
Both customers have new TE4xxP cards (one TE406P and one TE411P) and astersik stable (one using 1.0.9 and one sable-head (v1-0 07/26/2005)).

I've deugged astersik with the core-dump and saw where asterisk crashes:

dsp.c in function: "ast_dsp_digitreset"
In this issue "dsp" struct is NULL and then asterisk crashes.

Please see attached my very little patch.
I don't know if this is the right way to fix this problem, but it works for now.
I think you guys at Digium will fix this issue correctly with my hints.

Greetings,

Thomas Haeger.
Comments:By: Paul Cadach (pcadach) 2005-07-27 09:43:20

Please, attach full backtrace to help resolve the problem.

By: thaeger (thaeger) 2005-07-27 10:33:52

Sorry, but the customers system is closed for me now ... I forgot to copy the back trace .... but this issue is very easy to reproduce ... just make an incoming call with overlapdial ...


Greetings,

Thomas.

By: thaeger (thaeger) 2005-07-27 10:41:56

...hi....aehmm   I could still get the backtrace from the customer system ...it is attached ...

regards,

Thomas.

By: Mark Spencer (markster) 2005-08-02 22:36:58

Can you please check this with CVS head and confirm the issue does not occur there, and if it does occur there, please post an updated backtrace from CVS head.  Thanks!

By: thaeger (thaeger) 2005-08-08 03:38:50

Hi Mark,

unfortunately this is also an issue for the HEAD revision ... but unfortunately I can't get a backtrace because the customer system where I got the first backtrace, I can't install the HEAD rev. and get a new trace, because it's a production system ...
But , think it's very easy to reproduce this issue.
My opinion is that some things are wrong with the 2nd generation Firmware ..... because this seems not to be the only issue....

Regards,

Thomas.

By: Mark Spencer (markster) 2005-08-08 10:48:38

I think the correct patch is not to call it when dsp is NULL in the first place :)

By: Mark Spencer (markster) 2005-08-08 10:48:51

Might want to confirm this is not an issue in CVS head, btw...

By: Mark Spencer (markster) 2005-08-08 13:20:27

Or to clarify, thaeger, please confirm for me that the problem does not occur in CVS head.  Thanks!

By: thaeger (thaeger) 2005-08-08 13:55:39

Hi Mark,

to clarify .... this issu occurs also with CVS HEAD. One of the customers tested it, but this was the system where it isn't possible to debug with gdb for some reasons.

Regards,

Thomas.

By: thaeger (thaeger) 2005-08-08 13:55:47

Hi Mark,

to clarify .... this issue occurs also with CVS HEAD. One of the customers tested it, but this was the system where it isn't possible to debug with gdb for some reasons.

Regards,

Thomas.

By: Mark Spencer (markster) 2005-08-08 16:35:19

I need a backtrace on head.  I don't see any way this can be called on NULL dsp...

By: thaeger (thaeger) 2005-08-09 04:18:29

Hi Mark,

the customer tested it again with cvs head, and now everthing is working.
No more crashes, no more double dtmf.

But one questions: Will you fix it also in cvs stable ?


Greetings,

Thomas.

By: Michael Jerris (mikej) 2005-08-09 12:56:47

Can you please do an updated backtrace from 1.0 branch from cvs (stable from cvs by doing cvs co -r v1-0 asterisk).  This will also verify if this is still an issue in cvs stable.  Thanks

By: Malcolm Davenport (mdavenport) 2005-08-25 16:51:25

Fixed by MattF:
http://lists.digium.com/pipermail/asterisk-cvs/2005-August/007387.html