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 158375 - fix segfault in mp3 typefinding
fix segfault in mp3 typefinding
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: High blocker
: 0.8.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-11-15 15:26 UTC by Ronald Bultje
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
fix (836 bytes, patch)
2004-11-15 15:27 UTC, Ronald Bultje 		none Details | Review

Description Ronald Bultje 2004-11-15 15:26:26 UTC 
typefind a mp3 file. It's a core bug, we need to workaround it until a new core
release.
Comment 1 Ronald Bultje 2004-11-15 15:27:07 UTC 
Created attachment 33806 [details] [review]
fix
Comment 2 Thomas Vander Stichele 2004-11-23 12:17:02 UTC 
Can't reproduce this against either 0.8.7 install or HEAD of GStreamer core.

I used gst-typefind on the two .mp3's in our testsuite.

How can I reproduce ?
Comment 3 Ronald Bultje 2004-11-23 13:45:07 UTC 
You probably can't, becayuse you run a developer install. The theory is simple,
though. Core 0.8.7's typefind and spider will define a GstTypeFind structure
that is *not* zeroed explicitely. Developer installs will zero this, stripped
installs won't. The check for this function checks for it being zero and else
executes it. Since it's not zeroed, we access random memory and thus crash. The
workaround is to not use the function until a newer core has been released.

Just trust me, this is an issue. Thanks.
Comment 4 Thomas Vander Stichele 2004-11-23 16:50:42 UTC 
Well, I *don't* run a developer install.

But what can I do if people don't follow my QA ? sigh.

commited.