[Home]

Summary:ASTERISK-17627: bug
Reporter:brost_dark (brost_dark)Labels:
Date Opened:2011-03-31 13:58:46Date Closed:2011-06-07 14:04:57
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_backtrace.txt
( 1) backtrace-threads.txt
( 2) core-show-locks.txt
( 3) gdb.txt
Description:crash
Comments:By: Clod Patry (junky) 2011-03-31 16:28:59

You need to give MUCH MORE infos.
How did you create this crash?
Can you reproduce it anytime?
Also, you didn't run with DONT_OPTIMIZE.
By: brost_dark (brost_dark) 2011-03-31 16:53:22

I have two server with Asterisk 1.8.3 with IVR php AGI.
I can not tell when it turns out, but the Asterisk is crash each hour,
with DIAL i use PITCH_SHIFT.
i have 7 core dump, I can send if need be.
Installing a version 1.8.2.4 will solve this problem ?
By: David Woolley (davidw) 2011-04-01 05:26:31

The core file is of no use to anyone except you.

As already said, the backtraces are of little use unless you compiled the code with DONT_OPTIMIZE set, which you didn't.

core show locks will only work if you compiled with thread debugging enabled, although this doesn't look like a deadlock, at the moment.

Also, for future reference, the purpose of the summary field is provide a sufficient description of the problem that people seeing it can easily judge whether it is relevant to them.  "Bug" adds no information that is not already in the severity.


By: Paul Belanger (pabelanger) 2011-04-02 15:29:29

Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We would be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!