After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 617941 - Process /usr/libexec/tracker-miner-fs was killed by signal 11
Process /usr/libexec/tracker-miner-fs was killed by signal 11
Status: RESOLVED INCOMPLETE
Product: tracker
Classification: Core
Component: Miners
0.8.x
Other Linux
: Normal normal
: ---
Assigned To: tracker-general
Jamie McCracken
Depends on:
Blocks:
 
 
Reported: 2010-05-06 17:47 UTC by Deji Akingunola
Modified: 2011-01-03 01:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Crash backtace (33.99 KB, text/plain)
2010-05-06 17:47 UTC, Deji Akingunola
Details
Valgrind log (158.02 KB, application/octet-stream)
2010-05-13 16:32 UTC, Deji Akingunola
Details

Description Deji Akingunola 2010-05-06 17:47:11 UTC
Created attachment 160450 [details]
Crash backtace

Another crash in tracker detected by Fedora's Abrt tool (https://bugzilla.redhat.com/show_bug.cgi?id=589602).

Relevant info in the original bug include;
...
cmdline: /usr/libexec/tracker-miner-fs
component: tracker
crash_function: magazine_chain_pop_head
executable: /usr/libexec/tracker-miner-fs
global_uuid: 9d664742fb55284ccc0dbee8173a4ed0a5aa0b5b
kernel: 2.6.33.3-79.fc13.x86_64
package: tracker-0.8.4-1.fc13
rating: 3
reason: Process /usr/libexec/tracker-miner-fs was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)
How to reproduce: Nothing special. But i know it was crawling a shared samba
dir
Comment 1 Carlos Garnacho 2010-05-13 10:22:55 UTC
At first glance it either looks to me like a memory corruption, or a GIO bug. On the crashing thread there is nothing but GIO functions, and I find it quite suspicious that it crashes on allocating memory (Usually a symptom of memory corruption)

Can you ask the reporter about running tracker-miner-fs under valgrind?

$ G_SLICE=always_malloc valgrind --leak-check=full --num-callers=30 --log-file=valgrind.log ./tracker-miner-fs -v 3

and come back with the valgrind.log file?
Comment 2 Deji Akingunola 2010-05-13 16:32:55 UTC
Created attachment 160978 [details]
Valgrind log

The requested valgrind log file.
Comment 3 Tobias Mueller 2010-10-22 12:17:44 UTC
Reopening as the valgring log has been provided.
Comment 4 Aleksander Morgado 2010-11-03 13:07:44 UTC
(In reply to comment #2)
> Created an attachment (id=160978) [details]
> Valgrind log
> 
> The requested valgrind log file.

This valgrind log doesn't show any invalid read/write error. Was the log obtained while actually reproducing the crash?
Comment 5 Fabio Durán Verdugo 2011-01-03 01:47:18 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!