GNOME Bugzilla – Bug 362650
crash in Ekiga Softphone: Exiting while wengophone...
Last modified: 2006-10-17 10:06:22 UTC
Version: 2.0.3 What were you doing when the application crashed? Exiting while wengophone was running. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 1671168 vsize: 0 resident: 1671168 share: 0 rss: 487424 rss_rlim: 0 CPU usage: start_time: 1160830448 rtime: 0 utime: 104 stime: 0 cutime:0 cstime: 0 timeout: 104 it_real_value: 0 frequency: 489575 Backtrace was generated from '/usr/bin/ekiga' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see http://live.gnome.org/GettingTraces for more information about how to do so.
Perhaps another dup of http://bugzilla.gnome.org/show_bug.cgi?id=359655
I don't think the fact that wengophone has anything to do with the crash. There's something wrong in edgy which makes ekiga crash without giving a backtrace, and we can't find what. I run edgy and regularly try to make ekiga crash, but never managed to reproduce that :-(
Damien, I think you can mark all the "crash when closing" as duplicate Snark, there is nothing wrong in edgy, that crash is a case were bug-buddy doesn't do a good job. I get the crash every few tries on edgy, the backtrace with is not really useful though, there is no ekiga symbol. Running ekiga with valgrind doesn't seem to work, it looks like it's confused by something, is that a known issue? *** This bug has been marked as a duplicate of 359655 ***
What do you do exactly to get it to crash ? I tried various combinations of calling/idling/quitting but couldn't reproduce :-/ I don't know about valgrind issues... apart from the fact that it's incredibly slow, which is quite normal.
I open ekiga, I've never used it, I've no account configured nor any webcam on that box. I click on the cancel from the druid, close the ekiga window by the menu and then right click on the notify icon and exit. Every 10 tries or so it crashes, might be a race condition or something About valgrind, it does print things until: "==23344== Syscall param write(buf) points to uninitialised byte(s) ==23344== at 0x977B0FB: (within /usr/lib/debug/libpthread-2.4.so) ==23344== by 0x6CD193E: _X11TransSocketWrite (Xtranssock.c:2164) ==23344== Address 0xD76B479 is 361 bytes inside a block of size 16,384 alloc'd ==23344== at 0x4A1FB37: calloc (vg_replace_malloc.c:279) ==23344== by 0x6CC2416: XOpenDisplay (OpenDis.c:264) --23344-- DWARF2 CFI reader: unhandled CFI instruction 0:24 --23344-- DWARF2 CFI reader: unhandled CFI instruction 0:24 ==23344== ==23344== Conditional jump or move depends on uninitialised value(s) ==23344== at 0x9DB40B6: re_compile_fastmap_iter (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x9DB45A4: re_compile_fastmap (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x9DC6774: regcomp (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x88476A1: PRegularExpression::Compile(char const*, int) (in /usr/lib/libpt.so.1.10.2) ==23344== ==23344== Conditional jump or move depends on uninitialised value(s) ==23344== at 0x9DB40B6: re_compile_fastmap_iter (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x9DB45B9: re_compile_fastmap (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x9DC6774: regcomp (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x88476A1: PRegularExpression::Compile(char const*, int) (in /usr/lib/libpt.so.1.10.2) ==23344== ==23344== Thread 8: ==23344== Syscall param writev(vector[...]) points to uninitialised byte(s) ==23344== at 0x9DD9463: writev (in /usr/lib/debug/libc-2.4.so) ==23344== by 0x6CD18FB: _X11TransSocketWritev (Xtranssock.c:2185) ==23344== Address 0xD76B334 is 36 bytes inside a block of size 16,384 alloc'd ==23344== at 0x4A1FB37: calloc (vg_replace_malloc.c:279) ==23344== by 0x6CC2416: XOpenDisplay (OpenDis.c:264) " Then the program seems to run fast and no other log is printed on the command line (though valgrind doesn't exit before the program neither)