Summary:ASTERISK-18287: Processing in sig_pri.c corrupts memory
Reporter:Mark Murawski (kobaz)Labels:
Date Opened:2011-08-17 23:07:49Date Closed:2011-08-25 12:09:14
Versions: Frequency of
Description:Reproducibility is consistent.  But I don't know exactly what triggers this processing.

I'm seeing moh becomming corrupted after certain situations happen in dahdi.  I had a feeling this was dahdi related since my systems that are 100% sip have never seen this problem.

Once moh is corrupted, I'll see output like this from 'moh show classes':

Class: ring
       Mode: files
       Directory: /var/lib/asterisk/mohring
Class: default
Uniqueid: 1313602769.710
Meetme: 275394270d
Usernum: 13
CallerIDNum: 209
CallerIDName: 209
Duration: 5

       Directory: Channel: SIP/207-00000274
Value: minrxjitter=0.000000;maxrxjitter=0.000000;avgrxjitter=0.000000;stdevrxjitter=0.000000;reported_minjitter=0.000000;reported_maxjitter=0.000000;reported_avgjitter=0.000000;reported_stdevjitter=0.000000;
Uniqueid: 1313602769.708

       Application: 000000;
Uniqueid: 1313602769.708

       Format: unknown

I wrote a script to once a second do a moh show classes, and any time the classes returned are some crazy unexpected output, it will dump the output and note the time, so I can have an exact second that the moh became corrupted.

Moh became corrupted every single time I saw this in the console:[2011-08-17 10:19:53] DEBUG[13201] sig_pri.c: sig_pri_hangup 1
[2011-08-17 10:19:53] DEBUG[13201] sig_pri.c: Not yet hungup...  Calling hangup once with icause, and clearing call

Here is the output immediately following:
[2011-08-17 10:20:41] ERROR[19847] astobj2.c: bad magic number 0x65742f6e for 0xd6670f8
[2011-08-17 10:20:41] ERROR[19847] astobj2.c: bad magic number 0x65742f6e for 0xd6670f8
[2011-08-17 10:21:08] VERBOSE[30305] dnsmgr.c: [2011-08-17 10:21:08]     -- Refreshing DNS lookups.

Asterisk can continue on for a while but eventually crash, and in the meantime, moh is generally unavailable.
Comments:By: Mark Murawski (kobaz) 2011-08-25 12:09:14.516-0500

Closing due to having found more information.  This perhaps is nothing to do with dahdi.