[asterisk-bugs] [JIRA] (ASTERISK-24669) 13.1.0 Crashing but core dump

Rusty Newton (JIRA) noreply at issues.asterisk.org
Thu Jan 8 08:31:34 CST 2015


     [ https://issues.asterisk.org/jira/browse/ASTERISK-24669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-24669:
------------------------------------

    Description: 
<gmalsack> has anyone seen this issue on *13.1.0 http://pastebin.com/5zAdK6Fi - tail of full log here.... http://pastebin.com/58dj4ANB
<gmalsack> 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<mjordan> ...
<mjordan> get a full backtrace
<gmalsack> seems to be causing the ast binary to crash, even with safe_asterisk running the service dies and has to be manually restarted.
<mjordan> it's an abort, so yes
<mjordan> you'll need to get a full backtrace.
<gmalsack> ok, working on that now.
<gmalsack> Full backtrace -> http://pastebin.com/NQVr9ZUN
<mjordan> gmalsack: well, that's not good. That looks like a memory corruption, or invalid channel snapshot in a stasis message (which also shouldn't happen). You may need to run that under valgrind, but regardless, it is a bug

Here's the valgrind.log file for review...

[Edit - Remove as per issue tracker guidelines... ]


  was:
<gmalsack> has anyone seen this issue on *13.1.0 http://pastebin.com/5zAdK6Fi - tail of full log here.... http://pastebin.com/58dj4ANB
<gmalsack> 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<mjordan> ...
<mjordan> get a full backtrace
<gmalsack> seems to be causing the ast binary to crash, even with safe_asterisk running the service dies and has to be manually restarted.
<mjordan> it's an abort, so yes
<mjordan> you'll need to get a full backtrace.
<gmalsack> ok, working on that now.
<gmalsack> Full backtrace -> http://pastebin.com/NQVr9ZUN
<mjordan> gmalsack: well, that's not good. That looks like a memory corruption, or invalid channel snapshot in a stasis message (which also shouldn't happen). You may need to run that under valgrind, but regardless, it is a bug

Here's the valgrind.log file for review...

root at switch:~# cat valgrind.log 
==8221== Memcheck, a memory error detector
==8221== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8221== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==8221== Command: asterisk -vvvvcg
==8221== 
==8221== Invalid read of size 4
==8221==    at 0x52CEAE: logger_print_normal (logger.c:1229)
==8221==    by 0x52D5C7: ast_log_full (logger.c:1723)
==8221==    by 0x52DAC9: ast_log_callid (logger.c:1752)
==8221==    by 0x52F1ED: __ast_verbose_ap (logger.c:1833)
==8221==    by 0x530106: __ast_verbose (logger.c:1844)
==8221==    by 0x4CE9A3: __ast_codec_register (codec.c:302)
==8221==    by 0x4CF491: ast_codec_builtin_init (codec_builtin.c:807)
==8221==    by 0x4331DA: main (asterisk.c:4336)
==8221==  Address 0x7b07560 is 64 bytes inside a block of size 67 alloc'd
==8221==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8221==    by 0x52CE24: logger_print_normal (utils.h:535)
==8221==    by 0x52D5C7: ast_log_full (logger.c:1723)
==8221==    by 0x52DAC9: ast_log_callid (logger.c:1752)
==8221==    by 0x52F1ED: __ast_verbose_ap (logger.c:1833)
==8221==    by 0x530106: __ast_verbose (logger.c:1844)
==8221==    by 0x4CE9A3: __ast_codec_register (codec.c:302)
==8221==    by 0x4CF491: ast_codec_builtin_init (codec_builtin.c:807)
==8221==    by 0x4331DA: main (asterisk.c:4336)
==8221== 
==8221== Invalid read of size 4
==8221==    at 0x52CE99: logger_print_normal (logger.c:1229)
==8221==    by 0x52D5C7: ast_log_full (logger.c:1723)
==8221==    by 0x52DAC9: ast_log_callid (logger.c:1752)
==8221==    by 0x52F1ED: __ast_verbose_ap (logger.c:1833)
==8221==    by 0x530106: __ast_verbose (logger.c:1844)
==8221==    by 0x4CE9A3: __ast_codec_register (codec.c:302)
==8221==    by 0x4CF6A6: ast_codec_builtin_init (codec_builtin.c:813)
==8221==    by 0x4331DA: main (asterisk.c:4336)
==8221==  Address 0x7b0bdc4 is 68 bytes inside a block of size 70 alloc'd
==8221==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8221==    by 0x52CE24: logger_print_normal (utils.h:535)
==8221==    by 0x52D5C7: ast_log_full (logger.c:1723)
==8221==    by 0x52DAC9: ast_log_callid (logger.c:1752)
==8221==    by 0x52F1ED: __ast_verbose_ap (logger.c:1833)
==8221==    by 0x530106: __ast_verbose (logger.c:1844)
==8221==    by 0x4CE9A3: __ast_codec_register (codec.c:302)
==8221==    by 0x4CF6A6: ast_codec_builtin_init (codec_builtin.c:813)
==8221==    by 0x4331DA: main (asterisk.c:4336)
==8221== 
==8221== Thread 5:
==8221== Invalid read of size 4
==8221==    at 0x52CEAE: logger_print_normal (logger.c:1229)
==8221==    by 0x52D08B: logger_thread (logger.c:1358)
==8221==    by 0x5D9289: dummy_start (utils.c:1232)
==8221==    by 0x673C181: start_thread (pthread_create.c:312)
==8221==    by 0x719DEFC: clone (clone.S:111)
==8221==  Address 0x9c14e80 is 32 bytes inside a block of size 34 alloc'd
==8221==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8221==    by 0x52CE24: logger_print_normal (utils.h:535)
==8221==    by 0x52D08B: logger_thread (logger.c:1358)
==8221==    by 0x5D9289: dummy_start (utils.c:1232)
==8221==    by 0x673C181: start_thread (pthread_create.c:312)
==8221==    by 0x719DEFC: clone (clone.S:111)
==8221== 
==8221== Invalid read of size 4
==8221==    at 0x52CE99: logger_print_normal (logger.c:1229)
==8221==    by 0x52D08B: logger_thread (logger.c:1358)
==8221==    by 0x5D9289: dummy_start (utils.c:1232)
==8221==    by 0x673C181: start_thread (pthread_create.c:312)
==8221==    by 0x719DEFC: clone (clone.S:111)
==8221==  Address 0x984a754 is 36 bytes inside a block of size 38 alloc'd
==8221==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8221==    by 0x52CE24: logger_print_normal (utils.h:535)
==8221==    by 0x52D08B: logger_thread (logger.c:1358)
==8221==    by 0x5D9289: dummy_start (utils.c:1232)
==8221==    by 0x673C181: start_thread (pthread_create.c:312)
==8221==    by 0x719DEFC: clone (clone.S:111)
==8221== 
==8221== Thread 1:
==8221== Source and destination overlap in memcpy(0xffeffdab8, 0xffeffdab8, 16)
==8221==    at 0x4C2F71C: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8221==    by 0xDD1898A: pj_gethostip (in /usr/local/lib/libpj.so.2)
==8221==    by 0x3AE3A722: load_module (res_pjsip_multihomed.c:217)
==8221==    by 0x528B10: start_resource.part.8 (loader.c:980)
==8221==    by 0x529397: load_resource_list (loader.c:973)
==8221==    by 0x52B164: load_modules (loader.c:1331)
==8221==    by 0x43370C: main (asterisk.c:4555)
==8221== 
==8221== Conditional jump or move depends on uninitialised value(s)
==8221==    at 0x1150C958: speex_decode_int (in /usr/local/lib/libspeex.so.2)
==8221==    by 0x16459E75: speextolin_framein (codec_speex.c:227)
==8221==    by 0x5D1778: generate_computational_cost (translate.c:408)
==8221==    by 0x5D400B: __ast_register_translator (translate.c:1187)
==8221==    by 0x1645AE82: load_module (codec_speex.c:612)
==8221==    by 0x528B10: start_resource.part.8 (loader.c:980)
==8221==    by 0x529397: load_resource_list (loader.c:973)
==8221==    by 0x52B164: load_modules (loader.c:1331)
==8221==    by 0x43370C: main (asterisk.c:4555)
==8221== 
==8221== Conditional jump or move depends on uninitialised value(s)
==8221==    at 0x1150C965: speex_decode_int (in /usr/local/lib/libspeex.so.2)
==8221==    by 0x16459E75: speextolin_framein (codec_speex.c:227)
==8221==    by 0x5D1778: generate_computational_cost (translate.c:408)
==8221==    by 0x5D400B: __ast_register_translator (translate.c:1187)
==8221==    by 0x1645AE82: load_module (codec_speex.c:612)
==8221==    by 0x528B10: start_resource.part.8 (loader.c:980)
==8221==    by 0x529397: load_resource_list (loader.c:973)
==8221==    by 0x52B164: load_modules (loader.c:1331)
==8221==    by 0x43370C: main (asterisk.c:4555)
==8221== 
root at switch:~# 



> 13.1.0 Crashing but core dump
> -----------------------------
>
>                 Key: ASTERISK-24669
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24669
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.1.0
>         Environment: 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Gregory Malsack
>         Attachments: valgrind_debug.txt
>
>
> <gmalsack> has anyone seen this issue on *13.1.0 http://pastebin.com/5zAdK6Fi - tail of full log here.... http://pastebin.com/58dj4ANB
> <gmalsack> 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> <mjordan> ...
> <mjordan> get a full backtrace
> <gmalsack> seems to be causing the ast binary to crash, even with safe_asterisk running the service dies and has to be manually restarted.
> <mjordan> it's an abort, so yes
> <mjordan> you'll need to get a full backtrace.
> <gmalsack> ok, working on that now.
> <gmalsack> Full backtrace -> http://pastebin.com/NQVr9ZUN
> <mjordan> gmalsack: well, that's not good. That looks like a memory corruption, or invalid channel snapshot in a stasis message (which also shouldn't happen). You may need to run that under valgrind, but regardless, it is a bug
> Here's the valgrind.log file for review...
> [Edit - Remove as per issue tracker guidelines... ]



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list