[Home]

Summary:ASTERISK-15835: Asterisk crash - core dump at manager.c:2637
Reporter:Marcin Kowalczyk (kowalma)Labels:
Date Opened:2010-03-18 03:48:39Date Closed:2010-04-15 10:36:31
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hi,

I've just had crash related to manager.c

#0  0x080eae53 in process_events (s=0xb705b1bc) at manager.c:2637
2637                    while ( (eqe = NEW_EVENT(s)) ) {
(gdb) bt full
#0  0x080eae53 in process_events (s=0xb705b1bc) at manager.c:2637
       eqe = (struct eventqent *) 0xaa49fa50
       ret = 0
#1  0x080ec134 in process_message (s=0xb705b1bc, m=0xb705af58) at manager.c:3023
       action = "Login", '\0' <repeats 74 times>
       ret = 0
       tmp = (struct manager_action *) 0x9afc938
       user = 0xb705aaea "click"
       __PRETTY_FUNCTION__ = "process_message"
#2  0x080ec5d5 in do_message (s=0xb705b1bc) at manager.c:3120
       m = {hdrcount = 3, headers = {0xb705ab00 "Action: Login", 0xb705aae0 "Username: click", 0xb705aac0 "Secret: haslo", 0x0 <repeats 125 times>}}
       header_buf = "\000ecret: haslo\000k", '\0' <repeats 1009 times>
       res = 1
#3  0x080ec86a in session_do (data=0xa89760c8) at manager.c:3178
       ser = (struct ast_tcptls_session_instance *) 0xa89760c8
       session = (struct mansession_session *) 0x9c45290
       s = {session = 0x9c45290, f = 0x0, fd = 0}
       flags = 2050
       res = 0
       __PRETTY_FUNCTION__ = "session_do"
#4  0x0813fd03 in handle_tcptls_connection (data=0xa89760c8) at tcptls.c:223
       tcptls_session = (struct ast_tcptls_session_instance *) 0xa89760c8
       ssl_setup = (int (*)(SSL *)) 0x805e4c0 <SSL_accept@plt>
       ret = 350
       err = "\\?\005?", '\0' <repeats 20 times>, "\020", '\0' <repeats 15 times>, "`?\005?\210??\t\000\000\000\000\000\000\000\000??p*?\000\000\000@", '\0' <repeats 20 times>, "\004/?\000\000\000\000\024?\005?\000\000\000\000\030?\005?\034?\005?\200\031?\f\000\000\000\210n?\000?\237?\000\000\000\000`???\005?\tT?`??\f\000\000\000\004/?9\f\002\000?c\217\n\f\000\000\000??\000\000\000\000\000\000\000\000(?\005?\n?\024\b\001\000\000\000\f\000\000\000\030?\005??8?`??\210n?\t\200n?\t??\000\000\000\000\000"...
       __PRETTY_FUNCTION__ = "handle_tcptls_connection"
       cookie_funcs = {read = 0x813f594 <ssl_read>, write = 0x813f5be <ssl_write>, seek = 0, close = 0x813f5df <ssl_close>}
ASTERISK-1  0x0814c3a8 in dummy_start (data=0xa8a65a18) at utils.c:968
       __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {-1211580428, 0, 0, -1224363064, 526827664, 1032253934}, __mask_was_saved = 0}}, __pad = {0xb705b490, 0x0, 0xa7c93cf8, 0xb7d0382e}}
       __cancel_routine = (void (*)(void *)) 0x807616a <ast_unregister_thread>
       __cancel_arg = (void *) 0xb705bb90
       not_first_call = 0
       ret = (void *) 0xb7db8d7e
       a = {start_routine = 0x813f784 <handle_tcptls_connection>, data = 0xa89760c8, name = 0xa8ad1260 "handle_tcptls_connection started at [  270] tcptls.c ast_tcptls_server_root()"}
ASTERISK-2  0xb7c7c4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
No symbol table info available.
ASTERISK-3  0xb7d7361e in clone () from /lib/i686/cmov/libc.so.6
No symbol table info available.

(gdb) bt
#0  0x080eae53 in process_events (s=0xb705b1bc) at manager.c:2637
#1  0x080ec134 in process_message (s=0xb705b1bc, m=0xb705af58) at manager.c:3023
#2  0x080ec5d5 in do_message (s=0xb705b1bc) at manager.c:3120
#3  0x080ec86a in session_do (data=0xa89760c8) at manager.c:3178
#4  0x0813fd03 in handle_tcptls_connection (data=0xa89760c8) at tcptls.c:223
ASTERISK-1  0x0814c3a8 in dummy_start (data=0xa8a65a18) at utils.c:968
ASTERISK-2  0xb7c7c4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
ASTERISK-3  0xb7d7361e in clone () from /lib/i686/cmov/libc.so.6
(gdb)

We saw this issue in past with older versions of * as well.
Comments:By: Russell Bryant (russell) 2010-03-18 08:05:39

The Asterisk version field is set to "Older 1.6.1 - please test a newer version".  What version are you using?

By: Marcin Kowalczyk (kowalma) 2010-03-18 08:26:56

1.6.1.12 as every thing over that version has UDP port leak bug (ASTERISK-15581).

By: Leif Madsen (lmadsen) 2010-03-18 09:18:59

I'd say once that issue has been resolved, either try reproducing on a revision past the commit that closes that issue, or wait for a release with the fix in it (which should be within a month).

I'll leave this issue open for now, but reproducing this on a more recent version would certainly be ideal.

By: Marcin Kowalczyk (kowalma) 2010-03-18 09:36:03

I'm going holidays day after tomorrow thats why I will upgrade to 1.6.1.18 + patch after I'm back.
I saw this issue on 1.6.0.5, 1.6.0.8 as well. This happens very raerly - once a week/two but still happens. I'm not pretty sure how to reproduce it.
Via manager interface we query queue status & we are getting channel info for connections waiting in queue.



By: Leif Madsen (lmadsen) 2010-04-06 08:40:03

Just pinging this issue to see if you've had a chance to upgrade yet?

By: Marcin Kowalczyk (kowalma) 2010-04-06 12:56:20

Yeap - waiting for crash :-)

By: Evandro C├ęsar Arruda (ecarruda) 2010-04-06 14:03:44

Hey People,

We have a full reporting about this on https://issues.asterisk.org/view.php?id=16506

Please Fallow that, it's older than it.

By: Leif Madsen (lmadsen) 2010-04-15 10:36:31

Closed in favour of ASTERISK-15359