[asterisk-bugs] [JIRA] (ASTERISK-23248) Asterisk 1.8.23.0 Crashes Signal 11/Segfault

Matt Jordan (JIRA) noreply at issues.asterisk.org
Wed Feb 12 22:49:03 CST 2014


    [ https://issues.asterisk.org/jira/browse/ASTERISK-23248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215190#comment-215190 ] 

Matt Jordan commented on ASTERISK-23248:
----------------------------------------

So, I just noticed this in the backtrace:

{noformat}
Thread 2 (Thread 31029):
#0  0x0060e402 in __kernel_vsyscall ()
#1  0x00306653 in fts_read () from /lib/i686/nosegneg/libc.so.6
#2  0x080ae17b in ast_waitfor_nandfds (c=0x24baf10, n=1, fds=0x0, nfds=0, exception=0x0, outfd=0x0, ms=0x24baf14) at channel.c:3271
#3  0x080ae5bc in ast_waitfor (c=0xfe5e3c8, ms=29948) at channel.c:3536
#4  0x080b4e85 in __ast_request_and_dial (type=0x127a437c "SIP", format=64, requestor=0x0, data=0x127a4382, timeout=30000, outstate=0x24bb2ec, 
    cid_num=0x127a4392 "4152000401", cid_name=0x127a43a0 "Calling", oh=0x24bb184) at channel.c:5494
#5  0x08157080 in ast_pbx_outgoing_exten (type=0x127a437c "SIP", format=64, data=0x127a4382, timeout=30000, context=0x127a43aa "from-internal", 
    exten=0x127a43ba "*664", priority=1, reason=0x24bb2ec, synchronous=1, cid_num=0x127a4392 "4152000401", cid_name=0x127a43a0 "Calling", vars=0x1240fc60, 
    account=0x82386e6 "", channel=0x24bb2e8) at pbx.c:9065
#6  0x0812ddae in fast_originate (data=0xf728b58) at manager.c:3833
#7  0x081a0617 in dummy_start (data=0x11102e78) at utils.c:1075
#8  0x003e7939 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#9  0x003108ae in __init_misc () from /lib/i686/nosegneg/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
{noformat}

Note the {{Backtrace stopped: previous frame inner to this frame (corrupt stack?)}}. This is noted on all of the stack frames.

There's a number of ways it could have gotten in this state, but none are trivial to ascertain, even with the core file - which would be needed. It's also highly unlikely that anyone will be able to reproduce this.

See [http://stackoverflow.com/questions/9809810/gdb-corrupted-stack-frame-how-to-debug] for some information on pulling data out of the {{core}} file for this.

Although it's hard to point a finger at anything in particular, I'm suspicious of the Macros you were using here. The fact that you have what appears to be a corrupted stack - and that the memory was smashed - makes me wonder if you didn't run afoul of the Macro stack smashing problem. You certainly have some nested Macros here:

{noformat}
#12 0x0462c405 in _macro_exec (chan=0x12aa0468, data=0x2693eb8 "dial,15,TtrWwI,4154944930", exclusive=0) at app_macro.c:413
#13 0x0462d65e in macro_exec (chan=0x12aa0468, data=0x2693eb8 "dial,15,TtrWwI,4154944930") at app_macro.c:586
#14 0x0813e52f in pbx_exec (c=0x12aa0468, app=0xf8fd8a8, data=0x2693eb8 "dial,15,TtrWwI,4154944930") at pbx.c:1446
#15 0x08147cf5 in pbx_extension_helper (c=0x12aa0468, con=0x0, context=0x12aa07d4 "macro-dial", exten=0x12aa0824 "s", priority=11, label=0x0, 
    callerid=0xff6b1d8 "+17202047063", action=E_SPAWN, found=0x269627c, combined_find_spawn=1) at pbx.c:4489
#16 0x0814998b in ast_spawn_extension (c=0x12aa0468, context=0x12aa07d4 "macro-dial", exten=0x12aa0824 "s", priority=11, callerid=0xff6b1d8 "+17202047063", 
    found=0x269627c, combined_find_spawn=1) at pbx.c:5127
#17 0x0462c405 in _macro_exec (chan=0x12aa0468, data=0x2698d28 "exten-vm,4154944930,4154944930", exclusive=0) at app_macro.c:413
#18 0x0462d65e in macro_exec (chan=0x12aa0468, data=0x2698d28 "exten-vm,4154944930,4154944930") at app_macro.c:586
#19 0x0813e52f in pbx_exec (c=0x12aa0468, app=0xf8fd8a8, data=0x2698d28 "exten-vm,4154944930,4154944930") at pbx.c:1446
{noformat}

I'd change your Macros to Gosubs and see if that prevents the problem from cropping back up.

Your other option would be to run under valgrind.

Since it is nearly impossible for a bug marshal to reproduce this problem, I'm going to go ahead and close this out as "Can't Reproduce". If you're able to get some more meaningful data - either from valgrind or from the core file - let a bug marshal know and we can reopen this issue.
                
> Asterisk 1.8.23.0 Crashes Signal 11/Segfault
> --------------------------------------------
>
>                 Key: ASTERISK-23248
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23248
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 1.8.23.0
>         Environment: Linux 32-bit Cent OS 5.9 VM on XenServer 5.6 SP2
>            Reporter: Jamuel Starkey
>            Assignee: Rusty Newton
>         Attachments: ASTERISK-23248_backtrace.txt, cdr_adaptive_odbc.conf, cdr.conf, sip_config.txt
>
>
> Saw this crash.  Have backtrace with thread debugging enabled.  Guessing that it occurred during a hangup or CDR manipulation as that's all I see in the backtrace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list