| Summary: | ASTERISK-23635: Crash in framehook during ast_write when called by app_swift | ||||
| Reporter: | Jeremy Kister (jkister) | Labels: | |||
| Date Opened: | 2014-04-15 15:34:11 | Date Closed: | 2014-04-17 12:05:41 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | . I did not set the category correctly. | ||
| Versions: | 11.7.0 | Frequency of Occurrence | One Time | ||
| Related Issues: |
| ||||
| Environment: | Debian7/x64 | Attachments: | ( 0) backtrace1.txt ( 1) frame.txt | ||
| Description: | just happened to be watching the console when i watched Asterisk segfault. | ||||
| Comments: | By: Jeremy Kister (jkister) 2014-04-15 15:36:00.690-0500 not sure what information to provide; my config is quite large. i see app_swift was involved here but since I use app_swift extensively i'm not sure it's the culprit. By: Matt Jordan (mjordan) 2014-04-15 19:00:04.633-0500 It's highly likely to be {{app_swift}}. If you have the core file still, it'd be useful to know what the channel and frame pointers were. You can open the core file using {{gdb}} and get those values using the following: {noformat} # frame 0 # print *frame # print *chan {noformat} By: Jeremy Kister (jkister) 2014-04-15 21:27:19.761-0500 [^frame.txt] attached. By: Matt Jordan (mjordan) 2014-04-17 12:05:35.249-0500 So, the frame was the culprit - it is pointing to garbage. Since {{app_swift}} was responsible for calling {{ast_write}}, it is also responsible for ensuring that the frame it provides is a valid pointer. Most likely there is an off nominal path in there that is handing an uninitialized frame to {{ast_write}}. At this is not a bug in a module in Asterisk, I'm going to go ahead and close this out as "Not a Bug" in Asterisk. | ||||