[Home]

Summary:ASTERISK-08480: Seg fault on call made after manager connection
Reporter:Brad Templeton (bradtem)Labels:
Date Opened:2007-01-04 00:43:08.000-0600Date Closed:2007-01-08 15:17:10.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Run latest SVN trunk 1.4.   Connect with astman or similar.  Attempt to make SIP call from one channel to another.   Program segfaults inside pthread_kill, called from unref_event in main/manager.c.   From the look of it, the handle passed to pthread_kill (accept_thread_ptr) is never set or used anywhere in the system, so not too surprising it segfaults.

I could give you more debug output but this code is pretty obviously wrong so I doubt you need it!  BTW Asterisk reports version 49074 but svn reports "at revision 49411" so I don't know what's up with that.

static struct eventqent *unref_event(struct eventqent *e)
{
       struct eventqent *ret = AST_LIST_NEXT(e, eq_next);
       if (ast_atomic_dec_and_test(&e->usecount) && ret)
               pthread_kill(accept_thread_ptr, SIGURG);
       return ret;
}

****** ADDITIONAL INFORMATION ******

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47016880 (LWP 30508)]
0x00119950 in pthread_kill () from /lib/tls/libpthread.so.0
(gdb) bt full
#0  0x00119950 in pthread_kill () from /lib/tls/libpthread.so.0
No symbol table info available.
#1  0x083dc49c in ?? ()
No symbol table info available.
#2  0x02cd6418 in ?? ()
No symbol table info available.
#3  0x080b1aaa in session_do (data=0x1) at manager.c:645
       cr = 1651336557
       buf = 0x79646f "gister"
Comments:By: Serge Vecher (serge-v) 2007-01-04 08:24:43.000-0600

could you please upload the change as a patchfile?
By: Brad Templeton (bradtem) 2007-01-04 13:02:47.000-0600

Sorry, I don't have a patch.   I just am indicating where the segfault is, and noting it's pretty obvious the code is wrong, since pthread_kill is being called with the variable accept_thread_ptr which is never initialized or used anywhere else in the code tree.   I don't know what this code does or how it is invoked, myself, since the stack traceback starts at this function, presumably a callback.
By: Tilghman Lesher (tilghman) 2007-01-08 07:51:20.000-0600

Duplicate of ASTERISK-8443.  Already fixed in trunk.