[asterisk-bugs] [JIRA] (ASTERISK-26972) Crash in adaptive jitterbugger

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236788#comment-236788 ] 

Kevin Harwell commented on ASTERISK-26972:
------------------------------------------

If you have it (or can capture one next time) a debug log right before the crash could be helpful.

Also when this occurs do you happen to know what the call scenario was at the time? For instance was it just two people talking, in a conference, a transfer was happening, etc...?

Does it happen on the same endpoint every time or seemingly random? Either way the endpoint's configuration (from [pj]sip.conf) could also help point things in a direction if that too could be gathered.

> Crash in adaptive jitterbugger
> ------------------------------
>
>                 Key: ASTERISK-26972
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26972
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>    Affects Versions: 14.3.0
>            Reporter: Richard Kenner
>
> I've gotten three crashes with arithmetic exceptions in abstract_jb.c where 
> framedata->timer_interval is (way) over 100.  Here's the traceback for one of them:
> {noformat}
> #0  0x0000000000435018 in hook_event_cb (chan=<value optimized out>, 
>     frame=0x87a180, event=<value optimized out>, data=0x2aec10001690)
>     at abstract_jb.c:1010
> #1  0x000000000050ec25 in framehook_list_push_event (
>     framehooks=0x2aec100258b0, frame=0x1e7d3600, 
>     event=AST_FRAMEHOOK_EVENT_READ) at framehook.c:118
> #2  0x00000000004b9f0c in __ast_read (chan=0x1e71cc18, dropaudio=0)
>     at channel.c:3950
> #3  0x000000000047b9d9 in bridge_channel_handle_interval (
>     bridge_channel=0x2aec004702f8) at bridge_channel.c:1466
> #4  bridge_channel_wait (bridge_channel=0x2aec004702f8)
>     at bridge_channel.c:2619
> #5  0x000000000047c888 in bridge_channel_internal_join (
>     bridge_channel=0x2aec004702f8) at bridge_channel.c:2757
> #6  0x0000000000468a18 in ast_bridge_join (bridge=0x2aec005276d8, 
>     chan=0x1e71cc18, swap=0x0, features=0x2aec088b2b60, 
>     tech_args=<value optimized out>, flags=<value optimized out>)
>     at bridge.c:1713
> {noformat}
> and here are some things I've extracted from the dump:
> {noformat}
> (gdb) print (struct jb_framedata *) $rbp
> $6 = (struct jb_framedata *) 0x2aec10001690
> (gdb) p *$
> $7 = {jb_impl = 0x5dfa20, jb_conf = {flags = 909184, max_size = 700, 
>     resync_threshold = 1000, impl = "adaptive\000\000\000\020", 
>     target_extra = 40}, start_tv = {tv_sec = 1492522127, tv_usec = 824808}, 
>   last_format = 0x2aebcc0121f0, timer = 0x2aec1002d4c0, 
>   timer_interval = 4460210, timer_fd = 126, first = 1, jb_obj = 0x2aec10004230}
> {noformat}
> {noformat}
> (gdb) p *$6.last_format
> $8 = {name = 0x603455 "slin", codec = 0x2aebcc012110, attribute_data = 0x0, 
>   interface = 0x0}
> (gdb) print *$6.last_format->codec
> $9 = {id = 8, name = 0x603455 "slin", 
>   description = 0x60345a "16 bit Signed Linear PCM", 
>   type = AST_MEDIA_TYPE_AUDIO, sample_rate = 8000, minimum_ms = 10, 
>   maximum_ms = 70, default_ms = 20, minimum_bytes = 160, 
>   samples_count = 0x4ca520 <g726_length>, 
>   get_length = 0x4ca530 <slin_samples>, smooth = 1, mod = 0x0}
> (gdb) p/x 909184
> $10 = 0xddf80
> (gdb) p frame
> $11 = (struct ast_frame *) 0x87a180
> (gdb) print *frame
> $12 = {frametype = AST_FRAME_NULL, subclass = {integer = 0, format = 0x0, 
>     frame_ending = 0}, datalen = 0, samples = 0, mallocd = 0, 
>   mallocd_hdr_len = 0, offset = 0, src = 0x0, data = {ptr = 0x0, uint32 = 0, 
>     pad = "\000\000\000\000\000\000\000"}, delivery = {tv_sec = 0, 
>     tv_usec = 0}, frame_list = {next = 0x0}, flags = 0, ts = 0, len = 0, 
>   seqno = 0}
> {noformat}
> All three crashes were in the same place with the exact same bogus timer_interval.
> Is there anything else that would be useful to get out of this dump?  Obviously, going back in time and finding the frame that set timer_interval would be very useful, but I don't see how to get that from the dumps.  Suggestions?



--
This message was sent by Atlassian JIRA
(v6.2#6252)