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 590252 - [flacdec] Totem segfaults while seeking flac
[flacdec] Totem segfaults while seeking flac
Status: RESOLVED DUPLICATE of bug 575349
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-30 11:03 UTC by Michael Monreal
Modified: 2009-07-30 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG=*sink:5,flac*:5,*audio*:5 log (839.12 KB, application/x-lzma)
2009-07-30 11:06 UTC, Michael Monreal
Details

Description Michael Monreal 2009-07-30 11:03:55 UTC
After bug 578612 was fixed I still get occasional segfaults when seeking in flac files. The problem does not seem to be the same as bug 589849 as it does not occur at the end of a song.
Comment 1 Michael Monreal 2009-07-30 11:06:25 UTC
Created attachment 139554 [details]
GST_DEBUG=*sink:5,flac*:5,*audio*:5 log
Comment 2 Tim-Philipp Müller 2009-07-30 13:31:20 UTC
Since it's a crash, a stacktrace made with

 (gdb) thread apply all bt

would also be nice.
Comment 3 Michael Monreal 2009-07-30 14:09:57 UTC
[New Thread 0xb5f0bb90 (LWP 17108)]
[New Thread 0xb4fffb90 (LWP 17109)]
[New Thread 0xb47afb90 (LWP 17110)]
[Thread 0xb47afb90 (LWP 17110) exited]
[Thread 0xb4fffb90 (LWP 17109) exited]
[New Thread 0xb4fffb90 (LWP 17111)]
[Thread 0xb5f0bb90 (LWP 17108) exited]
[New Thread 0xb5f0bb90 (LWP 17112)]
[Thread 0xb4fffb90 (LWP 17111) exited]
[New Thread 0xb4fffb90 (LWP 17113)]
[New Thread 0xb47afb90 (LWP 17114)]
[New Thread 0xafee8b90 (LWP 17115)]
[New Thread 0xaf6e7b90 (LWP 17116)]
[New Thread 0xaeee6b90 (LWP 17117)]
[Thread 0xafee8b90 (LWP 17115) exited]

(totem:17102): GStreamer-CRITICAL **: gst_caps_is_fixed: assertion `GST_IS_CAPS (caps)' failed

(totem:17102): GStreamer-CRITICAL **: gst_caps_is_any: assertion `GST_IS_CAPS (caps)' failed

(totem:17102): GStreamer-CRITICAL **: gst_caps_is_empty: assertion `GST_IS_CAPS (caps)' failed

(totem:17102): GStreamer-CRITICAL **: gst_caps_is_any: assertion `GST_IS_CAPS (caps)' failed

(totem:17102): GStreamer-CRITICAL **: gst_caps_is_empty: assertion `GST_IS_CAPS (caps)' failed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4fffb90 (LWP 17113)]
0xb7e931a4 in gst_caps_subtract (minuend=0x8fc9880, subtrahend=0x8fc9640)
    at gstcaps.c:1382
1382	  sublen = subtrahend->structs->len;
(gdb) thread apply all bt

Thread 1 (Thread 0xb6d5a750 (LWP 17102))

  • #0 IA__g_type_is_a
    at gtype.c line 3192
  • #1 IA__g_signal_emit_valist
    at gsignal.c line 2917
  • #2 IA__g_signal_emit
    at gsignal.c line 3037
  • #3 gst_bus_async_signal_func
    at gstbus.c line 1098
  • #4 gst_bus_source_dispatch
    at gstbus.c line 761
  • #5 IA__g_main_context_dispatch
    at gmain.c line 1960
  • #6 g_main_context_iterate
    at gmain.c line 2591
  • #7 IA__g_main_loop_run
    at gmain.c line 2799
  • #8 IA__gtk_main
    at gtkmain.c line 1205
  • #9 main
    at totem.c line 278

Comment 4 Tim-Philipp Müller 2009-07-30 14:34:10 UTC
This looks very much like bug #575349, which I also got with flacdec, but that was possibly because I was only testing with flac, the original reporter was using mad as far as I can tell.
Comment 5 Michael Monreal 2009-07-30 15:46:48 UTC
If you think it's the same, feel free to mark as dupe, I will follow the other bug. I cannot reproduce this with my vorbis files but I just ripped to mp3 and I see the same problem there as well.
Comment 6 Tim-Philipp Müller 2009-07-30 16:11:59 UTC
> If you think it's the same, feel free to mark as dupe, I will follow the other
> bug. I cannot reproduce this with my vorbis files but I just ripped to mp3 and
> I see the same problem there as well.

Ok, that means it's not a bug in flacdec then and most likely a duplicate.

Unfortunately I have absolutely no idea where the issue might be. Sounds like a refcount problem somewhere, but where (and why does it not happen more often)?

It would be interesting to try a pipeline that doen't contain any basetransform-based elements (audioconvert/audioresample) to narrow it down a bit. Something like filesrc ! flacdec ! pulsesink or so.


*** This bug has been marked as a duplicate of 575349 ***