Summary: | ASTERISK-08140: Chanspy application in asterisk 1.4 ver crash the asterisk-segmentation fault (core dumped) | ||
Reporter: | mottano (mottano) | Labels: | |
Date Opened: | 2006-11-16 00:49:15.000-0600 | Date Closed: | 2007-01-10 10:24:42.000-0600 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) bigpbx_core.txt | |
Description: | Consuder i have 3 channels like 6002,6004,6006. I need to monitor the 6006 ,when 6004 and 6006 have conversation thro. chanspy (asterisk 1.4, beta3) In my chanspy dial plan is like.. exten => 6008,1,chanspy(SIP/6006 |wbq) when i dial 6008, i got the following message in console and immed. asterisk terminated .. ------------------------------------------------------------ *CLI> -- Executing [6006@from-sip:1] Dial("SIP/6002-08590248", "SIP/6006|15|tr") in new stack -- Called 6006 -- SIP/6006-08594188 is ringing -- SIP/6006-08594188 answered SIP/6002-08590248 -- Executing [6008@from-sip:1] ChanSpy("SIP/6004-08589040", "SIP/6006|wq") in new stack == Spying on channel SIP/6006-08594188 [Nov 11 15:19:37] NOTICE[8974]: app_chanspy.c:202 start_spying: Attaching SIP/6004-08589040 to SIP/6006-08594188 Segmentation fault (core dumped) linux:~ # --------------------------------------------------------------------------- ****** ADDITIONAL INFORMATION ****** i need to clarify, wethere the new future in chanspy,i.e,"Whispering mode" have functioning correctly. | ||
Comments: | By: Joshua C. Colp (jcolp) 2006-11-16 09:50:22.000-0600 Please try the latest 1.4 branch, I believe there were further improvements. If that also fails then please get a backtrace from the core dump. Instructions can be found in the doc directory, backtrace.txt - Thanks! By: Jason Parker (jparker) 2006-11-21 12:26:01.000-0600 Were you able to test the latest 1.4 branch? By: Mitch Sharp (bluecrow76) 2006-11-22 15:03:08.000-0600 Just posted bigpbx core.txt. Got back to the office today and found the system down. Investigated the core dump and found the segfault occured when someone used ChanSpy on a SIP channel. Hope the dump helps. By: Joshua C. Colp (jcolp) 2006-11-27 15:35:10.000-0600 Just to confirm - that is a relatively recent 1.4 checkout or still the beta? By: Mitch Sharp (bluecrow76) 2006-11-27 16:16:36.000-0600 This occured on a 1.4-beta3 install. The bigpbx_core.txt file is from that core dump. I've also had this happen recently on a 1.2.12.1 system with the following trace: (gdb) bt #0 0x00617fa9 in free () from /lib/tls/libc.so.6 #1 0x0805904d in ast_frfree (fr=0x6dbff4) at frame.c:277 #2 0x08061b8e in ast_channel_spy_free (spy=0xb7566910) at channel.c:1115 #3 0x00241693 in channel_spy (chan=0xb7a06200, spyee=0xb7a00ac0, volfactor=0xb7566a74, fd=0) at app_chanspy.c:341 #4 0x0024275d in chanspy_exec (chan=0xb7a06200, data=0xb756b0a0) at app_chanspy.c:508 ASTERISK-1 0x0809141d in pbx_extension_helper (c=0xb7a06200, con=Variable "con" is not available. ) at pbx.c:553 ASTERISK-2 0x080926e6 in __ast_pbx_run (c=0xb7a06200) at pbx.c:2230 ASTERISK-3 0x0809424c in pbx_thread (data=0x6dd804) at pbx.c:2517 ASTERISK-4 0x00962371 in start_thread () from /lib/tls/libpthread.so.0 ASTERISK-5 0x0067d9be in clone () from /lib/tls/libc.so.6 (gdb) bt full #0 0x00617fa9 in free () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0805904d in ast_frfree (fr=0x6dbff4) at frame.c:277 No locals. #2 0x08061b8e in ast_channel_spy_free (spy=0xb7566910) at channel.c:1115 f = Variable "f" is not available. (gdb) By: Serge Vecher (serge-v) 2006-11-29 15:50:41.000-0600 bluecrow76: as suggest by file, please try the latest svn branch checkout, at r > 48000 while waiting for 1.4-beta4. Thanks. By: Joshua C. Colp (jcolp) 2006-12-18 21:07:32.000-0600 If this is still not fixed please report back and we can go from there, which will probably requiring getting access to a box where this is happening so I can examine the core dump. By: jlimb (jlimb) 2006-12-22 02:05:47.000-0600 this may or may not be relative: on my 1.2.12.1 box I run chanspy with the (q) quiet option because if I don't I can crash asterisk every time by hanging up while chanspy is playing the name of the channel I am monitoring. By: Joshua C. Colp (jcolp) 2006-12-22 10:54:43.000-0600 Can you provide backtraces of these crashes? I attempted to recreate them using both 1.2.12.1 and the latest 1.2 but was unable to on my box. By: jlimb (jlimb) 2006-12-22 19:43:08.000-0600 Here is my crash on 1.2.12.1 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 #0 0x00a65fa9 in free () from /lib/tls/libc.so.6 (gdb) bt #0 0x00a65fa9 in free () from /lib/tls/libc.so.6 #1 0x0805904d in ast_frfree (fr=0xb29ff4) at frame.c:277 #2 0x08061b8e in ast_channel_spy_free (spy=0xb7a27910) at channel.c:1115 #3 0x00ff5693 in channel_spy (chan=0x9f54138, spyee=0x9f56b08, volfactor=0xb7a27a74, fd=0) at app_chanspy.c:341 #4 0x00ff675d in chanspy_exec (chan=0x9f54138, data=0xb7a2c0a0) at app_chanspy.c:508 ASTERISK-1 0x0809141d in pbx_extension_helper (c=0x9f54138, con=Variable "con" is not available. ) at pbx.c:553 ASTERISK-2 0x080926e6 in __ast_pbx_run (c=0x9f54138) at pbx.c:2230 ASTERISK-3 0x0809424c in pbx_thread (data=0xb2b804) at pbx.c:2517 ASTERISK-4 0x00bca371 in start_thread () from /lib/tls/libpthread.so.0 ASTERISK-5 0x00acb9be in clone () from /lib/tls/libc.so.6 (gdb) bt full #0 0x00a65fa9 in free () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0805904d in ast_frfree (fr=0xb29ff4) at frame.c:277 No locals. #2 0x08061b8e in ast_channel_spy_free (spy=0xb7a27910) at channel.c:1115 f = Variable "f" is not available. (gdb) By: Serge Vecher (serge-v) 2006-12-27 13:43:03.000-0600 what about 1.2.14? By: jlimb (jlimb) 2007-01-09 23:44:46.000-0600 As for me and my problem, It does not happen on 1.2.14. But it doesn't sound like my problem is the same as the initial reporter's problem. By: Serge Vecher (serge-v) 2007-01-10 10:24:30.000-0600 ok, op (mottano) hasn't responded for over a month. If the problem still persists with 1.4.0 release, please reopen the bug with a new backtrace attached. |