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 461253 - Crash when gst_base_transform_prepare_output_buffer is sent negative size.
Crash when gst_base_transform_prepare_output_buffer is sent negative size.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal critical
: 0.10.20
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-07-28 15:53 UTC by Laszlo Pandy
Modified: 2008-05-06 08:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Last few lines of the gst debug level 5 log before the crash (5.26 KB, text/plain)
2007-07-28 15:56 UTC, Laszlo Pandy
Details

Description Laszlo Pandy 2007-07-28 15:53:54 UTC
Steps to reproduce:
Short version:
1. Call gst_base_transform_prepare_output_buffer() with a negative size value, that when converted to an unsigned int will be a very large value.
2. Notice that gst_pad_alloc_buffer_full() takes in size as a gint, whereas gst_buffer_new_and_alloc() takes in size as a guint.
3. Watch g_malloc() fail as you cannot allocate such a large block of memory.

Long version (how I invoked the crash):
1. Run Jokosher and import an MP3 file.
2. Note that when using new in gstreamer CVS is the ability for mp3parse to do accurate seeks. Jokosher uses gnonlin, which does accurate seeking.
3. Play the audio and quickly seek from one place to another. I find it is easiest to reproduce when seeking backwards in short intervals such as seek to 10s, then 9s, then 8s as fast as you can click.
4. Everything crashes.


Stack trace:
GLib-ERROR **: gmem.c:135: failed to allocate 4294783552 bytes
aborting...

Program received signal SIGABRT, Aborted.

Thread NaN (LWP 23557)

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 abort
    from /lib/tls/i686/cmov/libc.so.6
  • #3 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #4 g_log
    from /usr/lib/libglib-2.0.so.0
  • #5 g_malloc
    from /usr/lib/libglib-2.0.so.0
  • #6 gst_buffer_new_and_alloc
    at gstbuffer.c line 327
  • #7 gst_pad_alloc_buffer_full
    at gstpad.c line 2682
  • #8 gst_base_transform_prepare_output_buffer
    at gstbasetransform.c line 953
  • #9 gst_base_transform_handle_buffer
    at gstbasetransform.c line 1460
  • #10 gst_base_transform_chain
    at gstbasetransform.c line 1585
  • #11 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #12 gst_pad_push
    at gstpad.c line 3621
  • #13 gst_proxy_pad_do_chain
    at gstghostpad.c line 191
  • #14 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #15 gst_pad_push
    at gstpad.c line 3621
  • #16 gst_proxy_pad_do_chain
    at gstghostpad.c line 191
  • #17 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #18 gst_pad_push
    at gstpad.c line 3621
  • #19 gst_proxy_pad_do_chain
    at gstghostpad.c line 191
  • #20 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #21 gst_pad_push
    at gstpad.c line 3621
  • #22 gst_proxy_pad_do_chain
    at gstghostpad.c line 191
  • #23 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #24 gst_pad_push
    at gstpad.c line 3621
  • #25 gst_mad_chain
    at gstmad.c line 1617
  • #26 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #27 gst_pad_push
    at gstpad.c line 3621
  • #28 gst_mp3parse_emit_frame
    at gstmpegaudioparse.c line 612
  • #29 gst_mp3parse_chain
    at gstmpegaudioparse.c line 972
  • #30 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #31 gst_pad_push
    at gstpad.c line 3621
  • #32 gst_type_find_element_chain
    at gsttypefindelement.c line 568
  • #33 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #34 gst_pad_push
    at gstpad.c line 3621
  • #35 gst_proxy_pad_do_chain
    at gstghostpad.c line 191
  • #36 gst_pad_chain_unchecked
    at gstpad.c line 3453
  • #37 gst_pad_push
    at gstpad.c line 3621
  • #38 gst_base_src_loop
    at gstbasesrc.c line 1775
  • #39 gst_task_func
    at gsttask.c line 192
  • #40 ??
    from /usr/lib/libglib-2.0.so.0
  • #41 ??
  • #42 ??
  • #43 ??
  • #44 ??
  • #45 ??
    from /usr/lib/libglib-2.0.so.0
  • #46 ??
  • #47 ??

Other information:
It seems from the backtrace that this is a bug in the new accurate seeking implementation in mp3parse, but nonetheless there should be a check for negative values in gst_base_transform_prepare_output_buffer() or gst_pad_alloc_buffer_full().
Comment 1 Laszlo Pandy 2007-07-28 15:56:36 UTC
Created attachment 92599 [details]
Last few lines of the gst debug level 5 log before the crash
Comment 2 Sebastian Dröge (slomo) 2008-05-06 08:42:46 UTC
Ok, basetransform and gst_pad_alloc*() will now complain about negative sizes instead of exploding :)

I don't think this was caused by a mp3parse bug though, it looks like one of the elements between mp3parse and the crasher transform the size wrong.
If you can still reproduce this bug could you file a new one with the complete pipeline and a complete GST_DEBUG=5 log?

2008-05-06  Sebastian Dröge  <slomo@circular-chaos.org>

        * gst/gstpad.c: (gst_pad_alloc_buffer_full):
        * libs/gst/base/gstbasetransform.c:
        (gst_base_transform_prepare_output_buffer):
        Don't allow negative sizes when allocating new buffers.
        Fixes bug #461253.