GNOME Bugzilla – Bug 133181
filesrc crashes
Last modified: 2009-08-15 18:40:50 UTC
I get reproducable crashes in filesrc when running a lot of files (usually happens around 300) through a pipeline of this kind: filesrc ! typefind ! fakesink A new pipeline (and new elements) are created for every file in my case. Valgrind only shows this: ==534== Invalid read of size 1 ==534== at 0x4394204A: mpeg_video_stream_type_find (gsttypefindfunctions.c:688) ==534== by 0x4029B97C: gst_type_find_factory_call_function (gsttypefind.c:193) ==534== by 0x42F70A7C: gst_type_find_element_chain (gsttypefind.c:522) ==534== by 0x40285D37: gst_pad_push (gstpad.c:2901) ==534== Address 0x9B885834 is 0 bytes after a block of size 2048 alloc'd ==534== at 0x4002CBEE: malloc (vg_replace_malloc.c:160) ==534== by 0x40507161: g_malloc (gmem.c:136) ==534== by 0x40266A2B: gst_buffer_new_and_alloc (gstbuffer.c:224) ==534== by 0x42F5F93C: gst_buffer_store_get_buffer (gstbufferstore.c:344) ==534== ==534== Invalid read of size 4 ==534== at 0x42F65746: gst_filesrc_get_mmap (gstfilesrc.c:503) ==534== by 0x42F2E720: get_group_schedule_function (gstoptimalscheduler.c:965) ==534== by 0x42F2E1F1: schedule_group (gstoptimalscheduler.c:842) ==534== by 0x42F2E2B5: gst_opt_scheduler_schedule_run_queue (gstoptimalscheduler.c:881) ==534== Address 0x44 is not stack'd, malloc'd or free'd ==534== ==534== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==534== Address not mapped to object at address 0x44 ==534== at 0x42F65746: gst_filesrc_get_mmap (gstfilesrc.c:503) ==534== by 0x42F2E720: get_group_schedule_function (gstoptimalscheduler.c:965) ==534== by 0x42F2E1F1: schedule_group (gstoptimalscheduler.c:842) ==534== by 0x42F2E2B5: gst_opt_scheduler_schedule_run_queue (gstoptimalscheduler.c:881) ==534== I'll attach the code that produces the problem. Compile and let loose on a folder with hundreds of mp3s like this: ./detect /some/folde/with/mp3s Cheers -Tim
Created attachment 23970 [details] causes crash in filesrc, usually after around 300-1000 files.
Couldn't reproduce the crash, fixed a bunch of issues though that might have caused it. Please close it if your issue is fixed. The attached program keeps buffers from every file it opens. Each buffer points to an mmaped data region of 4MB for each file, so after 300 files, the program has mmaped 1.2 GB of data. It's a nice stresstest at least ;)
Benjamin, are you saying hte testcase is wrong because it doesn't unref properly, or that we should use it as a test case in gstreamer ?
The test case did not unref properly (possibly there were other problems in filesrc as well, but they were fixed).