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 674073 - [0.11] mpegvideoparser segfaults
[0.11] mpegvideoparser segfaults
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.11.x
Other Mac OS
: Normal normal
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-04-13 20:07 UTC by Matej Knopp
Modified: 2012-05-21 18:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (732 bytes, patch)
2012-04-13 20:07 UTC, Matej Knopp
committed Details | Review
Revert previous patch (748 bytes, patch)
2012-05-21 14:26 UTC, Matej Knopp
none Details | Review

Description Matej Knopp 2012-04-13 20:07:18 UTC
Created attachment 212022 [details] [review]
Patch

last_sc is not reset every time a frame is being output, which can cause last_sc > buf_size in subsequent frame.
Comment 1 Wim Taymans 2012-04-14 08:43:57 UTC
commit d487c9cd78d68f080d275c09114e0b3ffc6a68d8
Author: Matej Knopp <matej.knopp@gmail.com>
Date:   Fri Apr 13 22:04:38 2012 +0200

    fix crash
    
    last_sc is not reset every time a frame is being output, which can cause
    last_sc > buf_size in subsequent frame.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=674073
Comment 2 Tim-Philipp Müller 2012-04-14 12:20:17 UTC
Could you please make sure to prefix the commit message with the element or plugin name in future? :)
Comment 3 Matej Knopp 2012-04-14 12:21:30 UTC
Sure
Comment 4 Mark Nauwelaerts 2012-05-21 13:45:52 UTC
Could you also explain (with whatever sample prompting this?) why/how come that last_sc is not being reset?

Baseclass should be passing _NEW_FRAME flag for any new/subsequent frame, which triggers a frame reset which in turn clears the last_sc state.

In summary, afaik, any subsequent frame should always have a reset last_sc, unless something going wrong at baseclass level which should then be fixed.  There is lot more parser state handling depending on that than a single field here.
Comment 5 Matej Knopp 2012-05-21 13:49:21 UTC
I can revert the fix locally and try to reproduce it again.
Comment 6 Matej Knopp 2012-05-21 14:25:49 UTC
So, I've reverted the patch and tested with the file I think caused the crash and it doesn't happen anymore. It might have been caused by the parser not splitting frames properly (part 3 of #674113). I think perhaps the fix should be reverted and if I encounter any more crashes I'll look into it.
Comment 7 Matej Knopp 2012-05-21 14:26:25 UTC
Created attachment 214565 [details] [review]
Revert previous patch
Comment 8 Mark Nauwelaerts 2012-05-21 18:22:08 UTC
OK, makes sense, so reverted with commit below.

commit f6942d851ca295681eea03e309b800cbbceb5327
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon May 21 16:37:37 2012 +0200

    mpegvideoparse: Revert "fix crash"
    
    This reverts commit 91210831ee672343a296f31357144359d5c2e768.
    
    Such explicit reset should not be needed as it is arranged for by
    the baseclass in unison with monitoring for a new frame by subclass.
    
    As such it might wrongfully hide something else going on ...
    
    See #674073.