GNOME Bugzilla – Bug 364113
crash in Ekiga Softphone: Nothing, I just started ...
Last modified: 2009-11-19 18:53:19 UTC
Version: 2.0.3 What were you doing when the application crashed? Nothing, I just started it (fresh reboot) and got this bugbuddy dialog. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 116654080 vsize: 0 resident: 116654080 share: 0 rss: 26664960 rss_rlim: 0 CPU usage: start_time: 1161505509 rtime: 0 utime: 219 stime: 0 cutime:165 cstime: 0 timeout: 54 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/ekiga' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1247730000 (LWP 5645)] [New Thread -1310676064 (LWP 6314)] [New Thread -1310000224 (LWP 6311)] [New Thread -1309733984 (LWP 6309)] [New Thread -1309467744 (LWP 6308)] [New Thread -1309201504 (LWP 6051)] [New Thread -1308628064 (LWP 6049)] [New Thread -1300235360 (LWP 6047)] [New Thread -1249653856 (LWP 5912)] [New Thread -1249387616 (LWP 5911)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 77634
Thread 1 (Thread -1247730000 (LWP 5645))
This may be connected to bug 363628
Closing and restarting Ekiga shows no problems. How do I get debugging symbols for Ekiga?
I realise this is not very useful information without a backtrace with debugging symbols, but I don't know how to get the debugging symbols. Unfortunately I can say that Ekiga is having problems here after the restart. I've encountered the following: * Unable to hangup on a call * Unable to register first one of my accounts * Unable to register either of my accounts * Ekiga seems to place the call (I hear a ring tone) even though it shows no accounts registered. * Right clicking the ekiga process icon and choosing quit does not stop Ekiga * Ekiga only quits after some time when I hear a 'call disconnected' signal (after about 30 seconds of silence) Sorry I can't be more specific, Duncan
Some clarification: I seem to be able to place the call (no one answering though). When I give up waiting I click the 'connect/disconnect' icon (top right) which only affects the audio - I stop hearing any audio ring tone. In the bottom of ekiga I can see that the call is still being placed, and then sometime later I get the disconnected signal and it returns to 'normal'. I'm doing a reboot I think.
Hmmm... the fact that the call doesn't end immediately is normal if the other end doesn't confirm immediately it received anything. The particular situation when you're behind a tightly closed firewall and don't receive other end's messages leads to having to wait for a timeout. The fact that you can't register could also be an indication that you don't receive registration notices. Aren't you behind a misbehaving firewall ? You may try ekiga -d 4 to get a log of what happens. Notice that those issues aren't related to the crash, and that rebooting is rarely a good solution.
The crash here is a crash in gnome-vfs, so I will reassign to gnome-vfs. The rest of the discussion related to your setup problems should move to ekiga-list.
Thanks Damien. Hello gnome-vfs devs!
*** Bug 369992 has been marked as a duplicate of this bug. ***
*** Bug 370225 has been marked as a duplicate of this bug. ***
*** Bug 370697 has been marked as a duplicate of this bug. ***
As Damien's comment suggested, this seems to not be much to do with Ekiga - it's been working flawlessly ever since. I suspect my Ekiga specific trouble was due to wireless network instability.
*** Bug 377418 has been marked as a duplicate of this bug. ***
Raising priority.
*** Bug 381075 has been marked as a duplicate of this bug. ***
*** Bug 389508 has been marked as a duplicate of this bug. ***
*** Bug 393752 has been marked as a duplicate of this bug. ***
*** Bug 405779 has been marked as a duplicate of this bug. ***
*** Bug 383722 has been marked as a duplicate of this bug. ***
*** Bug 409515 has been marked as a duplicate of this bug. ***
*** Bug 414176 has been marked as a duplicate of this bug. ***
*** Bug 406608 has been marked as a duplicate of this bug. ***
*** Bug 417171 has been marked as a duplicate of this bug. ***
*** Bug 429275 has been marked as a duplicate of this bug. ***
My opinion is that there are two bugs here : (1) in gnome_vfs_uri_to_string in gnome-vfs-uri.c, I see : string = g_string_new(uri->method_string); were uri is a parameter, not checked for NULL before going uri->... of course it crashes if NULL is given as a parameter. The function should really either cope with uri == NULL, or have a nice g_return_val_if_fail (2) fs_module_create points to libgnomeui, where this function just does gtk_file_system_gnome_vfs_new ; so there must be something wrong with this class ; I found two uses of gnome_vfs_uri_to_string in gtkfilesystemgnomevfs.c : (ii) in make_child_uri, where it is not possible to call gnome_vfs_uri_to_string with NULL ; (i) in gtk_file_system_gnome_vfs_get_parent, where gnome_vfs_uri_to_string is called on the result of gnome_vfs_uri_get_parent, where the situation isn't clear for me : there's an if () { ... } where I don't think returning NULL is possible, and then there's a return gnome_vfs_uri_dup (uri->parent); where I think NULL could occur. Hope this helps.
*** Bug 428749 has been marked as a duplicate of this bug. ***
*** Bug 437335 has been marked as a duplicate of this bug. ***
*** Bug 444892 has been marked as a duplicate of this bug. ***
*** Bug 455126 has been marked as a duplicate of this bug. ***
*** Bug 465001 has been marked as a duplicate of this bug. ***
*** Bug 439581 has been marked as a duplicate of this bug. ***
*** Bug 463958 has been marked as a duplicate of this bug. ***
*** Bug 441347 has been marked as a duplicate of this bug. ***
*** Bug 517352 has been marked as a duplicate of this bug. ***
The libgnomeui side of this doesn't apply any more since the vfs backend there has been removed some time ago. Lowering this now maybe seeing as there's been no new duplicates in almost two years.
After checking again I see that the function does indeed check for NULL before passing uri->method_string to g_string_new() and returns NULL in that case. Closing.