Ubuntu
tracker package

tracker-extract crashed with SIGSEGV in gst_type_find_factory_call_function()

Bug #141090 reported by Laur Mõtus on 2007-09-19

This bug report is a duplicate of: Bug #144748: totem/tracker crashed with SIGSEGV in sbc_typefind(). Edit Remove

Affects		Status	Importance	Assigned to	Milestone
	tracker (Ubuntu)	Invalid	High	Unassigned

Bug Description

Binary package hint: tracker

Apport-caught

ProblemType: Crash
Architecture: i386
Date: Wed Sep 19 02:09:41 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/tracker-extract
NonfreeKernelModules: nvidia
Package: tracker 0.6.2-0ubuntu3
PackageArchitecture: i386
ProcCmdline: tracker-extract /home/vprints/Desktop/trailer.wmv video/x-ms-wmv
ProcCwd: /home/vprints
ProcEnviron:
PATH=/home/vprints/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
LANG=et_EE.UTF-8
SHELL=/bin/bash
Signal: 11
SourcePackage: tracker
Stacktrace:
#0 0xb732376a in ?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
#1 0xbf9c492c in ?? ()
#2 0x00000000 in ?? ()
StacktraceTop:
?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
?? ()
?? ()
ThreadStacktrace:
.
Thread 1 (process 6370):
#0 0xb732376a in ?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
#1 0xbf9c492c in ?? ()
#2 0x00000000 in ?? ()
Title: tracker-extract crashed with SIGSEGV
Uname: Linux vprints-desktop 2.6.22-11-generic #1 SMP Mon Sep 17 03:45:58 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

Tags:

Revision history for this message

Laur Mõtus (vprints) wrote on 2007-09-19:

Dependencies.txt Edit (2.5 KiB, text/plain; charset="utf-8")
Disassembly.txt Edit (572 bytes, text/plain; charset="utf-8")
ProcMaps.txt Edit (11.1 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (669 bytes, text/plain; charset="utf-8")
Registers.txt Edit (491 bytes, text/plain; charset="utf-8")

Emilio Pozuelo Monfort (pochu) on 2007-09-19

Changed in tracker:
importance:	Undecided → Low

Revision history for this message

Apport retracing service (apport) wrote on 2007-09-20: Symbolic stack trace

Stacktrace.txt (retraced) Edit (8.5 KiB, text/plain)

StacktraceTop:gst_type_find_factory_call_function (factory=0x8077490, find=0xbf9c492c) at gsttypefindfactory.c:243
gst_type_find_helper_get_range (obj=0x8117008, func=0xb7e93730 <gst_proxy_pad_do_getrange>, size=0, prob=0xbf9c49f4) at gsttypefindhelper.c:238
gst_type_find_element_activate (pad=0x8110338) at gsttypefindelement.c:719
gst_pad_set_active (pad=0x8110338, active=1) at gstpad.c:648
activate_pads (pad=0x8110338, ret=0xbf9c4ab8, active=0xbf9c4b18) at gstelement.c:2486

Revision history for this message

Apport retracing service (apport) wrote on 2007-09-20: Symbolic threaded stack trace

ThreadStacktrace.txt (retraced) Edit (8.6 KiB, text/plain)

Changed in tracker:
importance:	Low → Medium

Emilio Pozuelo Monfort (pochu) on 2007-09-20

Changed in tracker:
importance:	Medium → Low

Revision history for this message

Laur Mõtus (vprints) wrote on 2007-09-20: Re: tracker-extract crashed with SIGSEGV

So why the "Low" ?

Revision history for this message

Emilio Pozuelo Monfort (pochu) wrote on 2007-09-20:

Because crashes in tracker-extract doesn't affect trackerd, and thus, it will just not index one file, but will index all the rest.

Also, this is probably a crash in gstreamer, and not in tracker itself...

Revision history for this message

Jamie McCracken (jamiemcc-blueyonder) wrote on 2007-09-26:

tracker-extract also self destructs after 10 secs if metadata is not extracted by then (or if it tries to consume more than 128MB ram)

we should really prevent tracker-extract crashes being reported as such

Revision history for this message

Alex Mayorga (alex-mayorga) wrote on 2007-09-28:

FWIW I've seen this crash on my system as well.

Revision history for this message

Robin Burchell (surreal-w00t) wrote on 2007-09-28:

This crash happened for me when tracker-extract attempted to do it's magic on a video file that had not fully downloaded.

Revision history for this message

Emilio Pozuelo Monfort (pochu) wrote on 2007-09-28:

Marking as high priority due to the number of duplicates.

Changed in tracker:
importance:	Low → High

Revision history for this message

Pedro Villavicencio (pedro) wrote on 2007-09-28:

#10

This is more like a dup of bug 144748 , not a tracker issue for me.

Revision history for this message

Jamie McCracken (jamiemcc-blueyonder) wrote on 2007-09-28:

#11

not a tracker issue

looks like a crash in gstreamer or oculd be tracker-extract self destructing if it takes longer than 10 secs or more then 128mb ram to extract

either way not a bug in tracker

Changed in tracker:
status:	New → Invalid

Revision history for this message

Emilio Pozuelo Monfort (pochu) wrote on 2007-09-28:

#12

This is indeed a duplicate of bug 144748, for those people who has this.
https://launchpad.net/bugs/144748

Revision history for this message

Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote on 2007-09-28:

#13

I got the same issues with a specific file.

This opensource game contains some wave file that caused this error.
http://sourceforge.net/projects/bloodfrontier/

However, the error occured WHILE unpacking the specific .wav file from the archive.
The interesting point here being that the file was still being written to at the time of indexing.

Gstreamer not being able to extract meta-data from a corrupted file should be no issue.
However, it should not extract data from currently opened files. They may be 'corrupted' for only a small time.

My suggestion:
- make sure to not index stuff that is currently being written (delay the meta-data extraction in that particular case)
- make sure the meta-data-extraction does not issue crash errors on corrupted files