GNOME Bugzilla – Bug 675786
tracker-0.14.1: tracker-miner-fs crashes due to calling g_hash_table_lookup() with NULL key
Last modified: 2012-10-29 18:03:42 UTC
I have gotten a crash in tracker-miner-fs in tracker-0.14.1 due to tracker-miner-fs's check_ignore_next_update() calling g_hash_table_lookup() with a GFile's uri as the key without checking that the uri is not NULL. The uri-less GFile in question was popped from fs->priv->items_created. I am not sure what is the best way to fix the problem; simply checking for a NULL uri is obvious, but it might paper over the real problem. Presumably, tracker-miner-fs should somehow avoid inserting uri-less or otherwise invalid entries into its fs->priv->items_created queue in the first place. The full backtrace: warning: core file may not match specified executable file. [New LWP 6626] [New LWP 6628] [New LWP 6627] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/libexec/tracker-miner-fs'. Program terminated with signal 11, Segmentation fault.
+ Trace 230203
Thread 1 (Thread 0x7f9be70d8780 (LWP 6626))
Hello Alexandre, Do you have a reliable way to reproduce this bug? I wouldn't expect URI to be NULL at any point. Are you getting any warnings in the logs/output?
(In reply to comment #1) > Hello Alexandre, > > Do you have a reliable way to reproduce this bug? No. > I wouldn't expect URI to be NULL at any point. Are you getting any warnings in > the logs/output? My ~/.local/share/tracker/tracker-miner-fs.log currently contains 48049 entries with "GLib-GIO-Critical **: g_file_get_uri: assertion `G_IS_FILE (file)' failed"
(In reply to comment #2) > (In reply to comment #1) > > Hello Alexandre, > > > > Do you have a reliable way to reproduce this bug? > > No. OK. > > I wouldn't expect URI to be NULL at any point. Are you getting any warnings in > > the logs/output? > > My ~/.local/share/tracker/tracker-miner-fs.log currently contains 48049 entries > with "GLib-GIO-Critical **: g_file_get_uri: assertion `G_IS_FILE (file)' > failed" Eek. Not good. OK, are you able to run the following commands: export G_MESSAGES_DEBUG=all # Might need this in your .bashrc tracker-control -t # Stop tracker processes tracker-control --set-log-verbosity=debug rm ~/.local/share/tracker/*.log tracker-control -s And then send us in the logs from tracker-miner-fs.log. That should help us identify what is causing these criticals/warnings. You shouldn't be getting *any*. I have a hunch about what might be causing this too, it might be related to GVFS mounts you have on that machine.
Actually, the G_MESSAGES_DEBUG part is likely unneeded because I fixed that in 0.14.1. So you can forget that.
Created attachment 213945 [details] tracker-miner-fs.log.xz (In reply to comment #3) > And then send us in the logs from tracker-miner-fs.log. That should help us > identify what is causing these criticals/warnings. You shouldn't be getting > *any*. > > I have a hunch about what might be causing this too, it might be related to > GVFS mounts you have on that machine. I have now experienced the same crash again; I am attaching my tracker-miner-fs.log (warning: 7MB when uncompressed). At the time of the crash, I was updating the gentoo-x86 Gentoo package tree from CVS (the tree contains ~200,000 files) and editing one of the ebuilds in it using gvim.
Output of "gvfs-mount -l" on the machine where tracker crashed: $ gvfs-mount -l Drive(0): MemoryStick Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(1): 134 MB File Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 134 MB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Drive(2): 4 Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 1.5 TB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Mount(0): 1.5 TB Filesystem -> file:///media/md4 Type: GProxyMount (GProxyVolumeMonitorGdu) Drive(3): SecureDigital Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(4): Generic- Compact Flash Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(5): SmartMedia Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(6): 750 GB Hard Disk Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 1.0 GB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Volume(1): 749 GB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Mount(0): 749 GB Filesystem -> file:///media/bck Type: GProxyMount (GProxyVolumeMonitorGdu) Drive(7): 1 Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 1.1 GB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Drive(8): 3 Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 2.6 GB Filesystem Type: GProxyVolume (GProxyVolumeMonitorGdu) Drive(9): CD/DVD Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(10): CompactFlash Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) Drive(11): 240 GB Solid-State Disk Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): 34 GB Unrecognized Type: GProxyVolume (GProxyVolumeMonitorGdu) Volume(1): 205 GB Unrecognized Type: GProxyVolume (GProxyVolumeMonitorGdu) Mount(0): 205 GB Unrecognized -> file:/// Type: GProxyMount (GProxyVolumeMonitorGdu) Mount(0): Filesystem root -> file:/// Type: GProxyMount (GProxyVolumeMonitorGdu)
This may be a duplicate of: https://bugzilla.gnome.org/show_bug.cgi?id=676489 That bug's symptoms are generally g_file_hash() and g_file_get_uri() warning about invalid GFile objects (due to a double unref happening earlier in Tracker's cache of GFile objects)
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 676489 ***
*** Bug 687108 has been marked as a duplicate of this bug. ***