Summary:ASTERISK-12672: crash in chan_iax
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2008-09-01 10:45:46Date Closed:2008-09-03 15:48:32
Versions:Frequency of
Description:(gdb) bt
#0  0x00dffcdf in __find_callno (callno=302, dcallno=7369, sin=0x9c4138, new=0, sockfd=12, return_locked=0, check_dcallno=1)
   at chan_iax2.c:1562
#1  0x00e005b9 in find_callno (callno=302, dcallno=7369, sin=0x9c4138, new=0, sockfd=12, full_frame=1) at chan_iax2.c:1685
#2  0x00e18111 in socket_process (thread=0x9c96fc8) at chan_iax2.c:7231
#3  0x00e21cfa in iax2_process_thread (data=0x9c96fc8) at chan_iax2.c:8660
#4  0x0810175d in dummy_start (data=0x9c95d10) at utils.c:912
ASTERISK-1  0x0085445b in start_thread () from /lib/libpthread.so.0
ASTERISK-2  0x007ac24e in clone () from /lib/libc.so.6


no additional information, sorry. Have no idea what preconditions are etc. Just found the core file.
Comments:By: Mark Michelson (mmichelson) 2008-09-03 15:22:21

The reason behind that crash doesn't seem very obvious at all. I suspect there's some memory corruption occurring. It sounds like this issue has happened to you only once ever though, so using valgrind to try to capture the problem may not be fruitful.

By: Leif Madsen (lmadsen) 2008-09-03 15:30:39

Does the original poster think he can reproduce the issue? If there is no useful information here and we can't reproduce, lets suspend this issue for now until there is more information to go on.

Thanks for looking putnopvut!

By: Dmitry Andrianov (dimas) 2008-09-03 15:39:16

No, I do not know how to reproduce it.
Also, I can not run valgrind because this happened on the production server and valgrind makes things damn slow there.

By: Leif Madsen (lmadsen) 2008-09-03 15:48:31

As this issue can't be reproduced right now, and you can't attach valgrind to the system, I'm going to close this issue. Please feel free to have the issue reopened should you be able to provide any additional information to move this forward.