Summary: | ASTERISK-15835: Asterisk crash - core dump at manager.c:2637 | ||
Reporter: | Marcin Kowalczyk (kowalma) | Labels: | |
Date Opened: | 2010-03-18 03:48:39 | Date Closed: | 2010-04-15 10:36:31 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | 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 |