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 133181 - filesrc crashes
filesrc crashes
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-02-02 03:30 UTC by Tim-Philipp Müller
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
causes crash in filesrc, usually after around 300-1000 files. (8.47 KB, application/octet-stream)
2004-02-02 03:57 UTC, Tim-Philipp Müller
Details

Description Tim-Philipp Müller 2004-02-02 03:30:19 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
Comment 1 Tim-Philipp Müller 2004-02-02 03:57:49 UTC
Created attachment 23970 [details]
causes crash in filesrc, usually after around 300-1000 files.
Comment 2 Benjamin Otte (Company) 2004-02-02 23:47:19 UTC
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 ;)
Comment 3 Thomas Vander Stichele 2004-02-11 18:00:19 UTC
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 ?
Comment 4 Tim-Philipp Müller 2004-02-13 12:16:28 UTC
The test case did not unref properly (possibly there were other 
problems in filesrc as well, but they were fixed).