GNOME Bugzilla – Bug 348960
crash on Baobab - Disk Usage Analyser
Last modified: 2006-07-30 18:58:21 UTC
What were you doing when the application crashed? Just launching it. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.15.90 2006-07-24 (Ubuntu) BugBuddy Version: 2.15.90 Memory status: size: 29503488 vsize: 0 resident: 29503488 share: 0 rss: 13262848 rss_rlim: 0 CPU usage: start_time: 1154021618 rtime: 0 utime: 48 stime: 0 cutime:42 cstime: 0 timeout: 6 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/baobab' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1224993104 (LWP 12417)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 69700
Thread 1 (Thread -1224993104 (LWP 12417))
>#4 0x080597ac in baobab_remote_connect_dialog_new () That's not clear. If you have just launched baobab, it will not try to launch the remote connect dialog... I cannot confirm for the moment. How did you launch it? On the terminal, or by means of the desktop icon in the menu?
It allways fail, either from menu or command line. Here's what baobab outputs when launched from command line: **** manu@hobbes:~$ baobab glibtop: This machine has 1 CPUs, 1 are being monitored. ** (bug-buddy:12851): WARNING **: Impossible de charger l'icône pour Ouvrir un dossier ** (bug-buddy:12851): WARNING **: Impossible de charger l'icône pour Signets Web d'Epiphany glibtop: This machine has 1 CPUs, 1 are being monitored. **** Last three lines probably come from bug-buddy. ii gnome-utils 2.15.90-0ubunt GNOME desktop utilities
What's the meaning of the 2 warnings (in english please..)?
Without a good stack trace from the crash (with symbols) it's very hard to determine what caused it. Can you provide us with one? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. I actually believe this to be the same crasg as in bug 323331. See the description of that bug and its duplicate. *** This bug has been marked as a duplicate of 323331 ***
<i>What's the meaning of the 2 warnings (in english please..)?</i> Forget about them, it's bug-buddy complaining about missing icons. <i>Without a good stack trace from the crash (with symbols) it's very hard to determine what caused it.</i> I'm not able to obtain better stack trace, even though I have ubuntu debug versions of most of gnome libraries.
Karsten, if it's really a dup of #323331, it should be reopened, since I'm using baobab from gnome-utils 1.15.90.
Emmanuel, you're probably right. I didn't check the date bug 323331 was supposed to be fixed in the first place. Thanks for pointing it out. To make good for this oversight, I just had a closer look at the code. ;) After some digging in CVS and the current code, it turns out, the fix for bug 323331 actually seems to be missing in the code. I'm going to reopen bug 323331, add the relevant comments and add you to the Cc list, so you'll be kept in the loop. (Emmanual, I assume, you are the reporter as well. ;)
I'd say we reopen this one... the other bug was effectively fixed and we double checked that the fix is still present in the current version even if the file names changed a bit when we imported in gnome-utils. However we need some more info... as Fabio said, we can't understand how that function ends up being called on startup.
Ok. I've compiled baobab from CVS and now I've got a more useful backtrace: 0x0805a70c in __udivdi3 () (gdb) bt
+ Trace 69790
The problem is, for some reason, my only mountpoint (/dev/hda) is exluded from scan list, so g_fs.total = 0. I guess a fix would be to add a check in baobab_init to not exclude root dir, like what is done in preference dialog code. I would also add a check in first_row to avoid a crash in case of g_fs.total = 0.
By the way, since it's not allowed to exclude root dir from scan list, it's corresponding line in preference dialog should be made insensitive, or not displayed at all.
How did you get to the preference dialog if the program is crashing at startup? Did you fix that?
> I guess a fix would be to add a check in baobab_init to not exclude root dir, > like what is done in preference dialog code. Root dir is included by glibtop ( glibtop_get_mountlist() ).
"my only mountpoint (/dev/hda) is exluded from scan list": do you mean you have it listed explicitely in GConf?
>How did you get to the preference dialog if the program is crashing at startup? >Did you fix that? I've fixed first_row to not crash on g_fs.total == 0. >> I guess a fix would be to add a check in baobab_init to not exclude root dir, >> like what is done in preference dialog code. > >Root dir is included by glibtop ( glibtop_get_mountlist() ). What I mean is, when reading gconf entries, I would ignore an entry excluding root dir from scan.
>"my only mountpoint (/dev/hda) is exluded from scan list": do you mean you have >it listed explicitely in GConf? Yes. I have no_scan = "/".
> Yes. I have no_scan = "/". Did you edited it manually, adding root dir? At program installation, that entry is NULL...
<i>Did you edited it manually, adding root dir?</i> You know, I'm experiencing enough crashes to not try to make software crash more... :) I didn't set no_scan entry to "/" via gconf-editor. I've got baobab installed on my system for quite a long time. It used to work until I've upgraded my ubuntu from dapper to edgy last week. Anyway, if you want to make baobab more robust with respect to broken gconf database, you really should make baobab_init ignore root dir for its excluded dir list, and fix first_row to not crash on g_fs.total == 0.
Emmanuel, thanks for cooperation. Now it is clear. The problem is coming from an old buggy-version of Baobab, which was leaving a "/" in gconf. I have fixed that by removing any forgotten "/" element found in gconf and don't allowing it anymore. I have also trapped the div by zero error. Fixed in cvs HEAD.