Summary: | ASTERISK-08180: asterisk crashes when transfering zap channel from idefisk to park extension 700 | ||
Reporter: | Jim Lawson (jubilex) | Labels: | |
Date Opened: | 2006-11-23 20:02:07.000-0600 | Date Closed: | 2006-11-30 14:11:03.000-0600 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) bug-1-stacktrace | |
Description: | I receive an incoming call from a Zap channel on my Mac running IDEFISK. I then hit transfer to ext 700, the default park extension, which is supposed to assign a specific park extension, and boom... segementation fault First happened on my first Asterisk install (1.4.0beta3), I reproduced it in the 1.4 SVN branch. Will attach backtrace ... ****** ADDITIONAL INFORMATION ****** First asterisk bug logged... please be gentle :-) | ||
Comments: | By: Jim Lawson (jubilex) 2006-11-23 20:06:15.000-0600 forgot to mention: platform - i686 (AMD AthlonXP) OS - Debian GNU/Linux vers - 3.1 (sarge/stable) By: Joshua C. Colp (jcolp) 2006-11-29 21:21:13.000-0600 Would it be possible to get access to the box where this core dump is? I need to examine it to find out the cause. Thanks! By: Jim Lawson (jubilex) 2006-11-30 09:25:02.000-0600 That's a little tricky as there are other applications running on this box and you would need root access. I could arrange for a shared "screen" session in which I enter passwords and watch the person doing the troubleshooting. If you want to go this route, let me know if SSH/screen access is enough and what times you are available (incl. timezone :-) If not, I am happy to provide coredumps/binaries, lists of installed packages, run tests, put printf()'s in the code, whatever. Let me know. By: Joshua C. Colp (jcolp) 2006-11-30 12:25:10.000-0600 Okay if you could open up the core dump and do the following it would be great: bt frame 0 print *iaxs[fr->callno] And put the output on here. Thanks! By: Joshua C. Colp (jcolp) 2006-11-30 14:11:03.000-0600 I was able to lab this up myself SO. Fixed in 1.2 as of revision 48157, 1.4 as of revision 48158, and trunk as of revision 48160. Thanks! |