Murdoch Coredump 20231029

[tsawyer]

Another core. Sorry no further details. If looks the same are others close and mention. core-asterisk-2023-10-29T17-49-36Z-full.txt

[tsawyer]

It occurred to me that this might have happened when attempt to reload the app_rpt module.

[tsawyer]

New crash last night.

core-asterisk-2023-11-17T09-48-03Z-full.txt

Console log. Console had been up a long while. core-asterisk-2023-11-17T09-48-03Z-full.txt

[InterLinked1]

Second crash is:

Thread 1 (Thread 0x7f5ff51d2700 (LWP 909049)):
#0  0x0000564c80a16367 in ast_sendtext_data (chan=chan@entry=0x7f5ff02ca9e0, msg=msg@entry=0x7f5ff8149480) at channel.c:4803
        res = 0
        body = 0x7f5ff814949c "!NEWKEY1!"
        content_type = 0x564c80bc2adf ""
        __PRETTY_FUNCTION__ = "ast_sendtext_data"
        __FUNCTION__ = "ast_sendtext_data"
#1  0x0000564c80a168a7 in ast_sendtext (chan=chan@entry=0x7f5ff02ca9e0, text=text@entry=0x7f601586584a "!NEWKEY1!") at channel.c:4867
        msg = 0x7f5ff8149480
        rc = <optimized out>
        attrs = {{type = AST_MSG_DATA_ATTR_BODY, value = 0x7f601586584a "!NEWKEY1!"}}
        __PRETTY_FUNCTION__ = "ast_sendtext"
#2  0x00007f6015838a35 in send_newkey (chan=chan@entry=0x7f5ff02ca9e0) at app_rpt/rpt_channel.c:468
        __PRETTY_FUNCTION__ = "send_newkey"
        __FUNCTION__ = "send_newkey"
#3  0x00007f60158267c5 in rpt_exec (chan=0x7f5ff02ca9e0, data=<optimized out>) at app_rpt.c:6917

First crash is completely unrelated:

Thread 1 (Thread 0x7fb511700700 (LWP 3715846)):
#0  0x00007fb51336fee3 in rpt_manager_do_xstat (ses=ses@entry=0x7fb5116ff4c0, m=m@entry=0x7fb5116ff9c0, str=0x7fb5201ee420 "") at app_rpt/rpt_manager.c:295
        rxchan = 0x0
        rxchanname = "dahdi/pseudo", '000' <repeats 243 times>
        pseudo = <optimized out>
        i = <optimized out>
        j = 0
        ns = <optimized out>
        lbuf = "000062065060061000T2546000T29275000T2526000T2525000T2523000T2522000T2521000T2505000T2503000T2509000T481470000T2528000T28020000C28025000C28026000T28024000T29447000T28028000T28029000T28023000T28021000T28022000T27439000C2534000000T27439000062061000T43245000T544864000T547812000T5"...
        strs = {0x0, 0x7fb5116f3d57 "T2503", 0x7fb5116f3d51 "T2505", 0x7fb5116f3d5d "T2509", 0x7fb5116f3d4b "T2521", 0x7fb5116f3d45 "T2522", 0x7fb5116f3d3f "T2523", 0x7fb5116f3d39 "T2525", 0x7fb5116f3d33 "T2526", 0x7fb5116f3d6b "T2528", 0x7fb5116f3dbe "C2534", 0x7fb5116f3d26 "T2546", 0x7fb5116f3db7 "T27439", 0x7fb5116f3d71 "T28020", 0x7fb5116f3da9 "T28021", 0x7fb5116f3db0 "T28022", 0x7fb5116f3da2 "T28023", 0x7fb5116f3d86 "T28024", 0x7fb5116f3d78 "C28025", 0x7fb5116f3d7f "C28026", 0x7fb5116f3d94 "T28028", 0x7fb5116f3d9b "T28029", 0x7fb5116f3d2c "T29275", 0x7fb5116f3d8d "T29447", 0x7fb5116f3d63 "T481470", 0x0, 0x0, 0x7fb5116f3f03 "T4447000", 0x7fb5116f3d57 "T2503", 0x7fb5116f3e13 "T45347", 0x7fb5116f3ec8 "T46533", 0x7fb5116f3ef4 "T465711", 0x7fb5116f3ee5 "T47243", 0x7fb5116f3dfd "T47398", 0x7fb5116f3daf "", 0x7fb5116f3d50 "", 0x7fb5116f3eec "T487470", 0x7fb5116f3f1c "T48748", 0x7fb5116f3d90 "447", 0x7fb5116f3f0c "T501660", 0x7fb5116f3da7 "3", 0x7fb5116f3d9f "29", 0x7fb5116f3eb9 "T50908", 0x7fb5116f3e1a "T50991", 0x7fb5116f3e68 "T516110", 0x7fb5116f3e30 "T51953", 0x7fb5116f3d3a "2525", 0x7fb5116f3f14 "T529413", 0x7fb5116f3e3d "T53185", 0x7fb5116f3ed6 "T537270", 0x7fb5116f3e4b "T541019", 0x7fb5116f3dd6 "T544864", 0x7fb5116f3e70 "T54572", 0x7fb5116f3d82 "026", 0x7fb5116f3de6 "T547811", 0x7fb5116f3dde "T547812", 0x7fb5116f3eb1 "T550113", 0x7fb5116f3df6 "T55075", 0x7fb5116f3e28 "T558520", 0x7fb5116f3ec0 "T558522", 0x7fb5116f3e21 "T55887", 0x7fb5116f3d98 "28", 0x7fb5116f3d71 "T28020", 0x7fb5116f3e7e "T574076", 0x7fb5116f3ede "T57980", 0x7fb5116f3dee "T594631", 0x7fb5116f3d2c "T29275", 0x7fb5116f3d42 "23", 0x7fb5116f3d67 "470", 0x0, 0x7fb5116f3d34 "2526", 0x7fb5116f3f0e "01660", 0x7fb5116f3e37 "T1973", 0x7fb5116f3ed0 "41971", 0x7fb5116f3e45 "28458", 0x7fb5116f3dd0 "43245", 0x7fb5116f3e6a "16110", 0x7fb5116f3d7c "25", 0x7fb5116f3de0 "47812", 0x7fb5116f3dd8 "44864", 0x7fb5116f3eab "29600", 0x7fb5116f3df0 "94631", 0x7fb5116f3e22 "55887", 0x7fb5116f3eba "50908", 0x7fb5116f3e1b "50991", 0x7fb5116f3d92 "7", 0x7fb5116f3d6b "T2528", 0x7fb5116f3e78 "27715", 0x7fb5116f3ed8 "37270", 0x7fb5116f3de8 "47811", 0x7fb5116f3d26 "T2546", 0x7fb5116f3d3c "25", 0x7fb5116f3d61 "9", 0x0 <repeats 2943 times>, 0x1 <error: Cannot access memory at address 0x1>, 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, 0xc6 <error: Cannot access memory at address 0xc6>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7fb5116fb5e0 "001", 0xe <error: Cannot access memory at address 0xe>, 0x559c56d34b3b "", 0x7fb532fcd180 <_IO_strn_jumps> "", 0x7fb5116fb760 "", 0x7fb532e69328 <__vfprintf_internal+1496> "H9330017205O020", 0x559c56d34b35 "%li.%d", 0x3 <error: Cannot access memory at address 0x3>, 0x0, 0x3000000000 <error: Cannot access memory at address 0x3000000000>, 0x7fb500000000 <error: Cannot access memory at address 0x7fb500000000>, 0x0, 0x7fb5116fb630 "1", 0x16 <error: Cannot access memory at address 0x16>, 0x0, 0x7fb532fcd540 <_IO_str_jumps> "", 0x7fb5116fb778 " 207267063265177", 0x0, 0x7fb5116fb670 "a", 0x17 <error: Cannot access memory at address 0x17>, 0x7fb512d7d18b "", 
<snip>

"$HOSTNAME coredump" is not really an effective way to report issues. A coredump is evidence of a bug, it isn't a bug in and of itself. It would help organization better if:

• Unrelated issues on the same node are opened as separate issues
• Related issues on different nodes (similar backtrace) are added to the related, existing issue
• Issue titles contained a hint of the problem area (e.g. the function name in Thread 1)

Right now it is difficult to correlate crashes since they all just say "coredump" which doesn't help, someone will need to go through all the backtraces in all the issues manually one by one and take notes first.

You don't have to analyze the backtrace when opening or adding to an issue, but I'd ask that you open the -full.txt file, go down to Thread 1 (which is always where the issue is in a crash fault), and use the function name in the backtrace to open an issue or add a comment to an existing one, as appropriate. This is generally how the Asterisk project triages issues, and this would help make them more actionable and keep data better organized, thanks!

[tsawyer]

Ok good. I didn't know how to approach reporting these core dumps.

• Confirming first crash title should have been titled rpt_manager_do_xstat and the second ast_sendtext_data?
• Is there anything else you'd like in the title?
• Would you like me go through each issue with a -full.txt and post snip of Thread 1?

[InterLinked1]

Ok good. I didn't know how to approach reporting these core dumps.

• Confirming first crash title should have been titled rpt_manager_do_xstat and the second ast_sendtext_data?

Including them in the title at a minimum at least would be very helpful.

• Is there anything else you'd like in the title?

Anything else you think is relevant but that alone would help a lot at least.

• Would you like me go through each issue with a -full.txt and post snip of Thread 1?

The snip of thread 1 isn't needed to be excerpted per se, I'll look at the full backtrace when looking on the issue, but just summarizing the function at the top of the stack trace in the title should help a lot - thanks!