GNOME Bugzilla – Bug 418991
crash in Ekiga Softphone: Starting up the applicat...
Last modified: 2007-06-27 12:50:49 UTC
Version: 2.0.3 What were you doing when the application crashed? Starting up the application Distribution: Debian 4.0 Gnome Release: 2.16.2 2006-12-03 (Debian) BugBuddy Version: 2.16.1 System: Linux 2.6.18-4-amd64 #1 SMP Wed Feb 21 14:29:38 UTC 2007 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: No Accessibility: Disabled Memory status: size: 200761344 vsize: 200761344 resident: 29696000 share: 21774336 rss: 29696000 rss_rlim: -1 CPU usage: start_time: 1174057826 rtime: 54 utime: 50 stime: 4 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/ekiga' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47687825961696 (LWP 4483)] [New Thread 1099716960 (LWP 4494)] [New Thread 1099450720 (LWP 4490)] [New Thread 1074272608 (LWP 4487)] [New Thread 1074006368 (LWP 4486)] (no debugging symbols found) 0x00002b5f2be4e00f in waitpid () from /lib/libpthread.so.0
+ Trace 119143
Thread 1 (Thread 47687825961696 (LWP 4483))
----------- .xsession-errors (119 sec old) --------------------- ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 --------------------------------------------------
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance! Using debian, having issues is pretty unusual...
Using this debug info, I tried to clear all apps/ekiga/devices/video keys (setting them to unset), and all of a sudden ekiga started up again. Still though, I don't think it should crash on a malformed gconf key?
+ Trace 119170
How come those keys could become malformed in the first place ?
I've never used ekiga before, I just installed it and went through the configuration pages. It autodetected my settings, so probably the application or the configuration tool put them there. I'm able to reproduce the crash now, if I set channel to '1' (I think it was like that after the config tool ran), it immediately crashes.
Can you post a backtrace ? Most probably your video driver has a bug and we can close this bug report as NOTGNOME.
Or PWLib (device drivers!)? J.
We still need a "thread apply all bt" to decide.
(gdb) thread apply all bt
+ Trace 120009
Thread 3 (Thread 1074272608 (LWP 7027))
Thread 1 (Thread 47240604672736 (LWP 7021))
Does it crash if you run it with : LC_ALL=C ekiga instead ? Actually, I see where it crashes. Could you try editing src/devices/videoinput.cpp:395 and see the values of the parameters (dialog_title and dialog_msg) that you are passing to gnomemeeting_warning_dialog_on_widget ? I have the feeling that : dialog_title is corrupted due to the driver being faulty. (I'm nearly sure it is the case because that code is very old and never gave any problem).
This one also crashes: robin@debianapple:~/ekiga$ LC_ALL=C ekiga These are dialog_title and dialog_msg (look pretty sane to me). --- Error while opening video device Built-in iSight --- A moving logo will be transmitted during calls. Notice that you can always transmit a given image or the moving logo by choosing "Picture" as video plugin and "MovingLogo" or "StaticPicture" as device. Could not open the chosen channel. ---
You are using a Macbook Pro Core 2 Duo ? (like me). However, I can not crash Ekiga here. Even if I put 1 as video channel instead of 0 (like it is probably the case for you) Can you have a look at the vsnprintf in gmdialog.c to see what's wrong ? (you seem to be able to code, so that would help a lot).
Yes, I'm using a Macbook Pro Core 2 Duo.. I found out the problem: in the function gnomemeeting_warning_dialog_on_widget the function vsnprintf (buffer, 1024, format, args) is called twice. The second call causes the problem (possibly a buffer overflow, so that would be the reason why you might not notice it, it may just be corrupting some other random memory). Removing the second call to vsnprintf (buffer, 1024, format, args) fixes the problem, and ekiga starts up fine. The second vsnprintf seems totally unnecessary to me, you might want to verify it's necessary, but from judging the code I think it can safely be removed. Yes, I'm able to code, but my C/C++ is a little bit rusty, thanks for the pointers.
I have applied your patch in HEAD, H_Release and gnome-2-14. In shorter words, it will be available in the next release of Ekiga. Thanks!
Just for the record, I figured out why vsnprintf() crashes the second time when called from the gnomemeeting_warning_dialog_on_widget function. va_end() should be called after returning from vsnprintf(), and resulting from that, before second use of the args parameter va_start() should be called again. So adding the statements va_end();va_start(format, args); also would have fixed this bug. Thanks for your quick responses, Robin
I don't like when I do not understand something and it was the case :) Thank you for your feedback and explanation !
*** Bug 443848 has been marked as a duplicate of this bug. ***
*** Bug 444379 has been marked as a duplicate of this bug. ***
*** Bug 451584 has been marked as a duplicate of this bug. ***