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 735320 - Crash when playing apple lossless files
Crash when playing apple lossless files
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: dont know
1.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-24 11:49 UTC by andreas.angerer89
Modified: 2016-02-21 23:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
sample file (444.05 KB, audio/x-m4a)
2014-08-24 11:49 UTC, andreas.angerer89 		Details

Description andreas.angerer89 2014-08-24 11:49:42 UTC 
Created attachment 284334 [details]
sample file

I have a problem when trying to play apple lossless files with gst-launch. This is what the terminal says:

{{{gst-launch-1.0 playbin uri=file:///home/andreas/01.m4a 
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Caught SIGSEGV
Spinning.  Please run 'gdb gst-launch-1.0 1207' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.}}}

Debugging with gdb gives:

{{{#0  0x00007ff1edc2603d in poll () at ../sysdeps/unix/syscall-template.S:81

+ Trace 233993

  • #1 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #2 g_main_loop_run
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #3 gst_bus_poll
    from /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
  • #4 ??
  • #5 ??
  • #6 __libc_start_main
    at libc-start.c line 287
  • #7 ?? 






Comment 1


Tim-Philipp Müller





          2014-08-24 12:30:05 UTC
        



Thanks for the sample file. I can't reproduce this myself, however.

What exact versions of GStreamer are you using?

Could you install debug packages for glib and gstreamer1.0 (libglib2.0-0-dbg and libgstreamer1.0-0-dbg on debian/ubuntu) and then get a new stack trace?

Could you get a full stack trace with '(gdb) thread apply all bt' ?

Could you run the above command line also in valgrind (after installing debug packages) ?






Comment 2


andreas.angerer89





          2014-08-24 12:39:00 UTC
        



Thanks for the help; this is quite annoying since a lot of players in Ubunut (e.g. totem) rely on gstreamer1. 

My exact version: libgstreamer1.0-0   1.2.4-0ubuntu1

Full backtrace:





+
Trace
    233994






Thread 4
          (Thread 0x7fb6c1801700 (LWP 16960))


    

  • 
#0
nanosleep

    
                at ../sysdeps/unix/syscall-template.S
                  line
                  81

    

    • 

  • 
#1
g_usleep

    
                at /build/buildd/glib2.0-2.40.0/./glib/gtimer.c
                  line
                  259

    

    • 

  • 
#2
fault_spin

    
                at gst-launch.c
                  line
                  109

    

    • 

  • 
#3
fault_handler_sighandler

    
                at gst-launch.c
                  line
                  90

    

    • 

  • 
#4
<signal handler called>

    • 

  • 
#5
gst_ffmpegauddec_frame

    
                at gstavauddec.c
                  line
                  644

    

    • 

  • 
#6
gst_ffmpegauddec_handle_frame

    
                at gstavauddec.c
                  line
                  757

    

    • 

  • 
#7
??

    
                from
                /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0

    

    • 

  • 
#8
??

    
                from
                /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0

    

    • 

  • 
#9
??

    
                from
                /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0

    

    • 

  • 
#10
gst_pad_chain_data_unchecked

    
                at gstpad.c
                  line
                  3760

    

    • 

  • 
#11
gst_pad_push_data

    
                at gstpad.c
                  line
                  3990

    

    • 

  • 
#12
gst_pad_push

    
                at gstpad.c
                  line
                  4093

    

    • 

  • 
#13
gst_single_queue_push_one

    
                at gstmultiqueue.c
                  line
                  1089

    

    • 

  • 
#14
gst_multi_queue_loop

    
                at gstmultiqueue.c
                  line
                  1338

    

    • 

  • 
#15
gst_task_func

    
                at gsttask.c
                  line
                  316

    

    • 

  • 
#16
g_thread_pool_thread_proxy

    
                at /build/buildd/glib2.0-2.40.0/./glib/gthreadpool.c
                  line
                  307

    

    • 

  • 
#17
g_thread_proxy

    
                at /build/buildd/glib2.0-2.40.0/./glib/gthread.c
                  line
                  764

    

    • 

  • 
#18
start_thread

    
                at pthread_create.c
                  line
                  312

    

    • 

  • 
#19
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  111

    

    • 













Comment 3


Sebastian Dröge (slomo)





          2014-08-28 07:26:13 UTC
        



Can you get a backtrace and valgrind with all debug symbols for all the relevant packages installed? The line in question here is

> /* this is where I lost my last clue on ffmpeg... */
> *got_data = 1;

This can only lead to a crash if the stack was corrupted by other code before.






Comment 4


Tim-Philipp Müller





          2016-02-21 23:32:00 UTC
        



I'm sorry, but I'm not sure what we can do about this without more information to go on. I think it needs to be debugged by someone who can reproduce the issue, and there's a good chance this has been fixed in newer versions.

It could also have been caused by installing incompatible system ffmpeg/libav versions from other repos.

If it's still an issue, someone will file a bug about it again sooner or later, perhaps we can reproduce it with that sample then or get more information.