GNOME Bugzilla – Bug 379801
Invalid free() when outgoing call is rejected.
Last modified: 2006-12-03 17:01:44 UTC
Steps to reproduce: 1. Launch ekiga (using provider cellip - mysecretary.net). 2. Dial out (in this case to a cellphone). 3. Reject the incoming call (on the cellphone). 4. Ekiga crashes (I can reliably reproduce this). Stack trace: *** glibc detected *** /usr/bin/ekiga: free(): invalid pointer: 0x08784fc8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb639b8bd] /lib/tls/i686/cmov/libc.so.6(__libc_free+0x84)[0xb639ba44] /usr/lib/libpt.so.1.10.2(_ZN14PAbstractArray15DestroyContentsEv+0x48)[0xb725a1c8] /usr/lib/libpt.so.1.10.2(_ZN10PContainer8DestructEv+0x57)[0xb725b207] /usr/bin/ekiga(_ZN7PStringD1Ev+0x18)[0x80764f8] /usr/lib/libopal.so.2.2(_ZN7SIP_PDUD0Ev+0x48)[0xb6d72848] /usr/lib/libopal.so.2.2(_ZN13SIPConnection20HandlePDUsThreadMainER7PThreadi+0x110)[0xb6d5a4b0] /usr/lib/libopal.so.2.2(_ZNK13SIPConnection30HandlePDUsThreadMain_PNotifier4CallER7PObjecti+0x25)[0xb6d663c5] /usr/lib/libpt.so.1.10.2(_ZN13PSimpleThread4MainEv+0x2f)[0xb724586f] /usr/lib/libpt.so.1.10.2(_ZN7PThread14PX_ThreadStartEPv+0x6d)[0xb722e04d] /lib/tls/i686/cmov/libpthread.so.0[0xb657f504] /lib/tls/i686/cmov/libc.so.6(__clone+0x5e)[0xb640251e] ======= Memory map: ======== 08048000-080fa000 r-xp 00000000 03:02 2041482 /usr/bin/ekiga 080fa000-08101000 rw-p 000b2000 03:02 2041482 /usr/bin/ekiga 08101000-0889d000 rw-p 08101000 00:00 0 [heap] ada6f000-ada70000 ---p ada6f000 00:00 0 ada70000-adab0000 rw-p ada70000 00:00 0 adab0000-adab1000 ---p adab0000 00:00 0 adab1000-ae2b1000 rw-p adab1000 00:00 0 aeab2000-aeab3000 ---p aeab2000 00:00 0 aeab3000-af2b3000 rw-p aeab3000 00:00 0 b15bf000-b15c0000 ---p b15bf000 00:00 0 b15c0000-b1621000 rw-p b15c0000 00:00 0 b1621000-b1700000 ---p b1621000 00:00 0 b1730000-b1731000 ---p b1730000 00:00 0 b1731000-b1771000 rw-p b1731000 00:00 0 b1771000-b17a1000 r-xp 00000000 03:02 1035325 /usr/lib/libcroco-0.6.so.3.0.1 b17a1000-b17a4000 rw-p 0002f000 03:02 1035325 /usr/lib/libcroco-0.6.so.3.0.1 b17a4000-b17cd000 r-xp 00000000 03:02 1032991 /usr/lib/libgsf-1.so.114.0.1 b17cd000-b17d0000 rw-p 00028000 03:02 1032991 /usr/lib/libgsf-1.so.114.0.1 b17d0000-b17d1000 rw-p b17d0000 00:00 0 b17d1000-b1800000 r-xp 00000000 03:02 1029680 /usr/lib/librsvg-2.so.2.16.0 b1800000-b1801000 rw-p 0002f000 03:02 1029680 /usr/lib/librsvg-2.so.2.16.0 b1801000-b1802000 ---p b1801000 00:00 0 b1802000-b2002000 rw-p b1802000 00:00 0 b2002000-b2003000 ---p b2002000 00:00 0 b2003000-b2043000 rw-p b2003000 00:00 0 b2043000-b2044000 ---p b2043000 00:00 0 b2044000-b2844000 rw-p b2044000 00:00 0 b2844000-b2845000 ---p b2844000 00:00 0 b2845000-b3045000 rw-p b2845000 00:00 0 b3045000-b3046000 ---p b3045000 00:00 0 b3046000-b3086000 rw-p b3046000 00:00 0 b3086000-b3087000 ---p b3086000 00:00 0 b3087000-b30c7000 rw-p b3087000 00:00 0 b30c7000-b3127000 rw-s 00000000 00:08 87326727 /SYSV00000000 (deleted) b3127000-b3128000 ---p b3127000 00:00 0 b3128000-b3168000 rw-p b3128000 00:00 0 b3168000-b316c000 r-xp 00000000 03:02 701836 /lib/tls/i686/cmov/libnss_dns-2.4.so b316c000-b316e000 rw-p 00003000 03:02 701836 /lib/tls/i686/cmov/libnss_dns-2.4.so b3186000-b318d000 r--p 00000000 03:02 2254678 /usr/share/locale-langpack/sv/LC_MESSAGES/gnome-vfs-2.0.mo b318d000-b31f1000 r--p 00000000 03:02 1697339 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttf b31f5000-b3204000 r-xp 00000000 03:02 701967 /lib/libbz2.so.1.0.3 b3204000-b3205000 rw-p 0000f000 03:02 701967 /lib/libbz2.so.1.0.3 b3223000-b3224000 r-xp 00000000 03:02 2072732 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so b3224000-b3225000 rw-p 00001000 03:02 2072732 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so b3225000-b3232000 r--s 00000000 03:02 1094644 /usr/share/mime/mime.cache b3232000-b3233000 ---p b3232000 00:00 0 b3233000-b3273000 rw-p b3233000 00:00 0 b3273000-b3274000 ---p b3273000 00:00 0 b3274000-b32b4000 rw-p b3274000 00:00 0 b32b4000-b32ba000 r-xp 00000000 03:02 2072739 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so b32ba000-b32bb000 rw-p 00005000 03:02 2072739 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so b32bb000-b32c2000 r-xp 00000000 03:02 1033879 /usr/lib/libfam.so.0.0.0 b32c2000-b32c3000 rw-p 00006000 03:02 1033879 /usr/lib/libfam.so.0.0.0 b32c3000-b32c8000 r-xp 00000000 03:02 702175 /lib/libacl.so.1.1.0 b32c8000-b32c9000 rw-p 00005000 03:02 702175 /lib/libacl.so.1.1.0 b32c9000-b32cc000 r-xp 00000000 03:02 701849 /lib/libattr.so.1.1.0 b32cc000-b32cd000 rw-p 00002000 03:02 701849 /lib/libattr.so.1.1.0 b32cd000-b32e3000 r--p 00000000 03:02 2252519 /usr/share/locale-langpack/sv/LC_MESSAGES/evolution-data-server-1.8.mo b32e3000-b32e5000 r--p 00000000 03:02 2254178 /usr/share/locale-langpack/sv/LC_MESSAGES/atk10.mo b32e5000-b32eb000 r--p 00000000 03:02 2254677 /usr/share/locale-langpack/sv/LC_MESSAGES/libgnomeui-2.0.mo b32eb000-b32f7000 r-xp 00000000 03:02 1534665 /usr/lib/gnome-vfs-2.0/modules/libfile.so b32f7000-b32f8000 rw-p 0000b000 03:02 Program received signal SIGABRT, Aborted. [Switching to Thread -1317598304 (LWP 3534)] 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 89756
Thread 1 (Thread -1247730000 (LWP 3183))
Other information: Running Ubuntu Edgy (6.10). (Using as many dbgsym packages as want to install.) Using Ekiga 2.0.3.
Thanks for taking the time to report this bug. Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols and which is not corrupted? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance! The problem can not be reproduced here. Setting priority as Low.
Further testing reveals that the bug is not triggered by rejecting the call, but also by not accepting it within a short period of time. When running through valgrind it does not abort but instead pops up a number (once I got 20 or so, once I got 2) of error dialogs saying "Invalid array index". Even further testing reveals that those dialogs pop up, and the valgrind message below appears even without connecting (just launching and waiting), this time running valgrind -v ekiga. Seeing how (from the regular gdb session) this
+ Trace 89795
seems to be where it's triggered makes the following excerpt from the valgrind log seem interesting (it's the only one not regarding gdk using calloc on previously malloced memory, or the soundsystem calling an ioctl with uninitialized data) (the message is also triggered at the same time as the dialogs): ==13264== Thread 13: ==13264== Invalid write of size 1 ==13264== at 0x572394A: SIP_PDU::Read(OpalTransport&) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x56FD605: SIPEndPoint::HandlePDU(OpalTransport&) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x56FD28E: SIPEndPoint::TransportThreadMain(PThread&, int) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x57098F4: SIPEndPoint::TransportThreadMain_PNotifier::Call(PObject&, int) const (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x4E7886E: PSimpleThread::Main() (osutils.cxx:2199) ==13264== by 0x4E6104C: PThread::PX_ThreadStart(void*) (tlibthrd.cxx:1340) ==13264== by 0x59A1503: start_thread (in /lib/tls/i686/cmov/libpthread-2.4.so) ==13264== by 0x5B8D51D: clone (in /lib/tls/i686/cmov/libc-2.4.so) ==13264== Address 0x77EAA84 is 4 bytes before a block of size 1 alloc'd ==13264== at 0x4021492: realloc (vg_replace_malloc.c:306) ==13264== by 0x4E8DF78: PAbstractArray::InternalSetSize(int, int) (contain.cxx:988) ==13264== by 0x4E8E0AB: PString::SetSize(int) (contain.cxx:1641) ==13264== by 0x4E8EFC7: PContainer::SetMinSize(int) (contain.cxx:782) ==13264== by 0x5723916: SIP_PDU::Read(OpalTransport&) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x56FD605: SIPEndPoint::HandlePDU(OpalTransport&) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x56FD28E: SIPEndPoint::TransportThreadMain(PThread&, int) (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x57098F4: SIPEndPoint::TransportThreadMain_PNotifier::Call(PObject&, int) const (in /usr/lib/libopal.so.2.2.3) ==13264== by 0x4E7886E: PSimpleThread::Main() (osutils.cxx:2199) ==13264== by 0x4E6104C: PThread::PX_ThreadStart(void*) (tlibthrd.cxx:1340) ==13264== by 0x59A1503: start_thread (in /lib/tls/i686/cmov/libpthread-2.4.so) ==13264== by 0x5B8D51D: clone (in /lib/tls/i686/cmov/libc-2.4.so) Unfortunately I seem to be having little luck getting gdb/valgrind to pick up the opal debug symbols. --15587-- Reading syms from /usr/lib/libopal.so.2.2.3 (0x4F44000) --15587-- Reading debug info from /usr/lib/libopal.so.2.2.3... --15587-- ... CRC mismatch (computed AAE95E15 wanted DF5CDA77) --15587-- Reading debug info from /usr/lib/debug/usr/lib/libopal.so.2.2.3... --15587-- warning: DiCfSI 0xFFA29B37 .. 0xFFA29B38 outside segment 0x4F44000 .. 0x5997FFF --15587-- warning: DiCfSI 0xFFA22F53 .. 0xFFA22F54 outside segment 0x4F44000 .. 0x5997FFF --15587-- warning: DiCfSI 0xFFA22F4F .. 0xFFA22F50 outside segment 0x4F44000 .. 0x5997FFF I'll attach the valgrind -v log and look into rebuilding the opal package with debugging symbols locally sometime later.
Created attachment 77233 [details] valgrind -v ekiga
I don't think that valgrind indicates teh source of the problem. (It is a double free). Can you mail me privately account information so that I can reproduce the problem?
I could reproduce the problem on my machine thanks to the information that you gave me. The problem is that your provider was sending a malformed "180 Ringing" response, and OPAL was deducing a negative value for the contentLength of the body. I have added guards against that and I have tested, it works well. The patch is available here : http://openh323.cvs.sourceforge.net/openh323/opal/src/sip/sippdu.cxx?r1=2.113&r2=2.114 It has been backported to the Phobos branch of OPAL, it means that both CVS HEAD and Ekiga 2.0.4 will contain the fix. Thanks for reporting it, and providing the relevant information allowing me to fix it!