totem/tracker crashed with SIGSEGV in sbc_typefind()

Bug #144748 reported by BorgCymru on 2007-09-25
498
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bluez-utils (Ubuntu)
High
Unassigned
Nominated for Gutsy by Stéphane Loeuillet

Bug Description

Binary package hint: totem

loads of errors on reboot after software updates

ProblemType: Crash
Architecture: i386
Date: Wed Sep 19 23:42:02 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/totem
NonfreeKernelModules: nvidia
Package: totem-gstreamer 2.20.0-0ubuntu1
PackageArchitecture: i386
ProcCmdline: totem
ProcCwd: /home/richard
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: totem
Stacktrace:
 #0 0xb501e76a in ?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
 #1 0xbf97674c in ?? ()
 #2 0x00000000 in ?? ()
StacktraceTop:
 ?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
 ?? ()
 ?? ()
Title: totem crashed with SIGSEGV
Uname: Linux Control1 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

BorgCymru (borgcymru) wrote :

StacktraceTop:gst_type_find_factory_call_function (factory=0x8107db0, find=0xbf97674c) at gsttypefindfactory.c:243
gst_type_find_helper_get_range (obj=0x847b800, func=0xb74a9730 <gst_proxy_pad_do_getrange>, size=0, prob=0xbf976814) at gsttypefindhelper.c:238
gst_type_find_element_activate (pad=0x82ccce0) at gsttypefindelement.c:719
gst_pad_set_active (pad=0x82ccce0, active=1) at gstpad.c:648
activate_pads (pad=0x82ccce0, ret=0xbf9768d8, active=0xbf976938) at gstelement.c:2486

Changed in totem:
importance: Undecided → Medium

The crash happens to /usr/lib/gstreamer-0.10/libgstbluetooth.so which is a bluez-utils file, reassigning

Marcel: we seem to get a bunch of crash reports due to this - do you know anything about it?

Daniel Holbach (dholbach) wrote :

#0 sbc_typefind (tf=0xbf97674c, ignore=0x0) at gstbluetooth.c:41
  [Error: gstbluetooth.c was not found in source tree]

---

   37 static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
   38 {
   39 guint8 *data = gst_type_find_peek(tf, 0, 1);
   40
   41 if (*data != 0x9c) /* SBC syncword */
   42 return;
   43
   44 gst_type_find_suggest(tf, GST_TYPE_FIND_POSSIBLE, SBC_CAPS);
   45 }

Marcel Holtmann (holtmann) wrote :

I have no idea why this happens. I was using the Bluetooth GStreamer plugin all the time and never had a problem. Didi something in the GStreamer API changed? Can gst_type_find_peek() return NULL?

Changed in bluez-utils:
importance: Medium → High
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

bug #145907 has some details

'If you have a file that is 0 bytes and try to open it with totem it crashes with

[Thread debugging using libthread_db enabled]
[New Thread 47611481099904 (LWP 20302)]
/bin/sh: /usr/bin/esd: not found
[New Thread 1082132816 (LWP 20309)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47611481099904 (LWP 20302)]
0x00002aaaacee0110 in ?? () from /usr/lib/gstreamer-0.10/libgstbluetooth.so
(gdb)

Easy to reproduce via "touch ./a.mp3 && totem ./a.mp3"'

Emilio Pozuelo Monfort (pochu) wrote :

For your information, this bug was also affecting tracker:
https://bugs.launchpad.net/bugs/141090

I don't feel like marking more than 20 bugs as dups of this one (it's not possible to just make the master of them), and marking also newer crashes which will be filled under tracker.

I thought you may want to know this has too more dups.

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

Replying to comment #8 (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/144748/comments/8) :

gst_type_find_peek ()
Returns : the requested data, or NULL if that data is not available.

Extracted from gst docs (via devhelp)

So yes, it misses a NULL ptr check !

description: updated

bluez-utils (3.19-0ubuntu2) gutsy; urgency=low

  * Add patch from upstream CVS to avoid crashing on zero-length files.

 -- Tollef Fog Heen <email address hidden> Fri, 28 Sep 2007 14:57:52 +0200

Changed in bluez-utils:
status: Confirmed → Fix Released
To post a comment you must log in.