GNOME Bugzilla – Bug 304136
Crash when trying to play a dv file after query for length from iterating pipeline. MPG files work fine.
Last modified: 2006-01-16 10:11:09 UTC
Steps to reproduce: 1. Hacked version of kiss kde video player demonstrates problem. http://www.nocturnalatl.com/gstreamer.html 2. Query the length on a dv file using pipeline. filesrc ! decodebin ! fakesink. unref the pipeline. then try to play the same file in a thread. 3. Stack trace:
+ Trace 59639
Other information: I previously sent an email to the mailing list and received help. Thank you. After some changes in my application I thought I had fixed the problem. Once I reinstated the file length query, dv files started crashing again but mpg files using the same threaded pipeline are playing fine. I was able to re-create the problem in a quick hack of the kiss kde video player. note: restart the player between every test because of my bad hack job. :)
I don't see a crash. Can you please install gst-plugins debug symbols, and provei a full backtrace for all threads (thread apply all bt)? Also see http://live.gnome.org/GettingTraces.
I installed the gst-plugin symbols. Here's another backtrace. I previously forgot to mention the crash happens randomly. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 25876)] 0x400636f2 in gst_structure_free (structure=0x809f6d0) at gststructure.c:224 224 for (i = 0; i < structure->fields->len; i++) { Current language: auto; currently c (gdb) thread apply all bt
+ Trace 59883
Thread 5 (Thread 49156 (LWP 25878))
Thread 4 (Thread 32771 (LWP 25877))
Thread 3 (Thread 16386 (LWP 25876))
Thank you; the problem is thread 3 frame 4. Can you please run this under valgrind (--tool=memcheck) and see if there's any related errors? It should give an error about accessing an already free'ed variable. I'd like to know when it was free'ed (but attaching the whole log is ok, too).
Hope this helps. Valgrind spewed a lot of errors but they appeared to be basically the same. So, I grabbed thread 3 and added the summary. ==26440== Thread 3: ==26440== Invalid write of size 4 ==26440== at 0x1E71F59D: _dv_bitstream_new_buffer (in /usr/lib/libdv.so.4.0.0) ==26440== by 0x1E71AACC: dv_decode_full_frame (in /usr/lib/libdv.so.4.0.0) ==26440== by 0x1E7121C9: gst_dvdec_loop (gstdvdec.c:1078) ==26440== by 0x1DCC51F7: loop_group_schedule_function (gstoptimalscheduler.c:1451) ==26440== by 0x1DCC4792: schedule_group (gstoptimalscheduler.c:1222) ==26440== by 0x1DCC4A68: gst_opt_scheduler_schedule_run_queue (gstoptimalscheduler.c:1274) ==26440== by 0x1DCC4BCA: schedule_chain (gstoptimalscheduler.c:1331) ==26440== by 0x1DCC8623: gst_opt_scheduler_iterate (gstoptimalscheduler.c:2790) ==26440== by 0x1B953CE2: gst_scheduler_iterate (gstscheduler.c:744) ==26440== by 0x1B92B2C5: gst_bin_iterate_func (gstbin.c:1281) ==26440== by 0x1B9678BA: gst_marshal_BOOLEAN__VOID (gstmarshal.c:509) ==26440== by 0x1BA3AEC8: (within /usr/lib/libgobject-2.0.so.0.600.3) ==26440== Address 0x1DA2AFD4 is 12 bytes inside a block of size 36 free'd ==26440== at 0x1B9047ED: free (vg_replace_malloc.c:152) ==26440== by 0x1E71A460: dv_decoder_free (in /usr/lib/libdv.so.4.0.0) ==26440== by 0x1E7127CC: gst_dvdec_change_state (gstdvdec.c:1129) ==26440== by 0x1B9365C5: gst_element_set_state_func (gstelement.c:2853) ==26440== by 0x1B936304: gst_element_set_state (gstelement.c:2796) ==26440== by 0x1B92A084: set_kid_state_func (gstbin.c:841) ==26440== by 0x1B929FCB: gst_bin_foreach (gstbin.c:805) ==26440== by 0x1B92A376: gst_bin_change_state (gstbin.c:903) ==26440== by 0x1DA76E90: gst_decode_bin_change_state (gstdecodebin.c:930) ==26440== by 0x1B9365C5: gst_element_set_state_func (gstelement.c:2853) ==26440== by 0x1B92A56E: gst_bin_set_state (gstbin.c:953) ==26440== by 0x1B936304: gst_element_set_state (gstelement.c:2796) ==26440== More than 30000 total errors detected. I'm not reporting any more. ==26440== Final error counts will be inaccurate. Go fix your program! ==26440== Rerun with --error-limit=no to disable this cutoff. Note ==26440== that errors may occur in your program without prior warning from ==26440== Valgrind, because errors are no longer being displayed. ==26440== ==26438== ==26438== ERROR SUMMARY: 30000 errors from 198 contexts (suppressed: 223 from 9) ==26438== malloc/free: in use at exit: 1487530 bytes in 25117 blocks. ==26438== malloc/free: 234517 allocs, 209400 frees, 45438063 bytes allocated. ==26438== For counts of detected errors, rerun with: -v ==26438== searching for pointers to 25117 not-freed blocks. ==26438== checked 5533480 bytes. ==26438== ==26438== LEAK SUMMARY: ==26438== definitely lost: 25881 bytes in 82 blocks. ==26438== possibly lost: 1040 bytes in 26 blocks. ==26438== still reachable: 1460609 bytes in 25009 blocks. ==26438== suppressed: 0 bytes in 0 blocks.
Do you still need more info on this? I can attach the whole log. It doesn't really crash when run with valgrind so the info you need may be missing. Any idea's?
I'll need the full log.
Created attachment 47242 [details] valgrind log Here's the whole log. This one actually captured a crash. thanks.
Seems like a libdv bug or so, it access memory that really no longer exists, and I don't think we even provide it that memory, we release any references to it in _change_state(). Maybe Wim knows more?
Is libdv keeping any global state or something? I'd be surprised if the problem was there. Lots of folks use dv pipelines. I am inclined to close this as obsolete; dv scrubbing works fine in 0.10. Rob do you have any opinion about that?
I would agree that it is obsolete at this time. thanks.
Cheers. Do let us know of problems in 0.10.