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 570761 - [goom] crash in plugin_info_init allocating 260kB struct on stack
[goom] crash in plugin_info_init allocating 260kB struct on stack
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.21
Other All
: Normal normal
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-02-06 08:33 UTC by Snark
Modified: 2010-06-28 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Trace (3.83 KB, application/octet-stream)
2010-06-28 07:55 UTC, Snark
  Details
goom: don't allocate 260kB struct on the stack (3.99 KB, patch)
2010-06-28 08:11 UTC, Tim-Philipp Müller
committed Details | Review

Description Snark 2009-02-06 08:33:35 UTC
Ekiga's experimental gstreamer code for video input leads to a crash ; here is the pipeline :
audiotestsrc ! goom ! ffmpegcolorspace ! appsink max_buffers=2 drop=true caps=video/x-raw-yuv,format=(fourcc)I420,width=176,height=144,framerate=(fraction)25/1 name=ekiga_sink

which works ok for video preview, but leads to the following trace when entering a call :
Program received signal SIGSEGV, Segmentation fault.

Thread 2983979920 (LWP 11309)

  • #0 memcpy
    from /lib/i686/cmov/libc.so.6
  • #1 plugin_info_init
    at plugin_info.c line 132
  • #2 goom_init
    at goom_core.c line 65
  • #3 gst_goom_init
    at gstgoom.c line 190
  • #4 IA__g_type_create_instance
    at /tmp/buildd/glib2.0-2.16.6/gobject/gtype.c line 1575
  • #5 g_object_constructor
    at /tmp/buildd/glib2.0-2.16.6/gobject/gobject.c line 1046
  • #6 IA__g_object_newv
    at /tmp/buildd/glib2.0-2.16.6/gobject/gobject.c line 937
  • #7 IA__g_object_new_valist
    at /tmp/buildd/glib2.0-2.16.6/gobject/gobject.c line 986
  • #8 IA__g_object_new
    at /tmp/buildd/glib2.0-2.16.6/gobject/gobject.c line 795
  • #9 gst_element_factory_create
    at gstelementfactory.c line 405
  • #10 gst_element_factory_make
    at gstelementfactory.c line 474
  • #11 _gst_parse_yyparse
    at ./grammar.y line 568
  • #12 _gst_parse_launch
  • #13 gst_parse_launch_full
  • #14 gst_parse_launch
  • #15 GST::VideoInputManager::open
    at ../../../../lib/engine/components/gstreamer//gst-videoinput.cpp line 120
  • #16 Ekiga::VideoInputCore::internal_open
    at ../../../lib/engine/videoinput/videoinput-core.cpp line 504
  • #17 Ekiga::VideoInputCore::start_stream
    at ../../../lib/engine/videoinput/videoinput-core.cpp line 343
  • #18 PVideoInputDevice_EKIGA::Start
    at ../../../../lib/engine/components/opal/opal-videoinput.cpp line 147
  • #19 OpalVideoMediaStream::Open()
    from /usr/lib/libopal.so.3.5-beta3
  • #20 OpalConnection::OpenMediaStream(OpalMediaFormat const&, unsigned int, bool)
    from /usr/lib/libopal.so.3.5-beta3
  • #21 OpalPCSSConnection::OpenMediaStream(OpalMediaFormat const&, unsigned int, bool)
    from /usr/lib/libopal.so.3.5-beta3
  • #22 OpalCall::OpenSourceMediaStreams(OpalConnection&, OpalMediaType const&, unsigned int, OpalMediaFormat const&)
    from /usr/lib/libopal.so.3.5-beta3
  • #23 SIPConnection::OnReceivedSDPMediaDescription(SDPSessionDescription&, unsigned int)
    from /usr/lib/libopal.so.3.5-beta3
  • #24 SIPConnection::OnReceivedSDP(SIP_PDU&)
    from /usr/lib/libopal.so.3.5-beta3
  • #25 SIPConnection::OnReceivedOK(SIPTransaction&, SIP_PDU&)
    from /usr/lib/libopal.so.3.5-beta3
  • #26 SIPConnection::OnReceivedResponse(SIPTransaction&, SIP_PDU&)
    from /usr/lib/libopal.so.3.5-beta3
  • #27 SIPTransaction::OnReceivedResponse(SIP_PDU&)
    from /usr/lib/libopal.so.3.5-beta3
  • #28 SIPInvite::OnReceivedResponse(SIP_PDU&)
    from /usr/lib/libopal.so.3.5-beta3
  • #29 SIPEndPoint::SIP_PDU_Thread::Main()
    from /usr/lib/libopal.so.3.5-beta3
  • #30 PThread::PX_ThreadStart(void*)
    from /usr/lib/libpt.so.2.5-beta3
  • #31 start_thread
    from /lib/i686/cmov/libpthread.so.0
  • #32 clone
    from /lib/i686/cmov/libc.so.6

Comment 1 Tim-Philipp Müller 2010-02-22 19:01:06 UTC
Hrm, this crash doesn't really make sense at all. Can you still reproduce this? Have you tried running it in valgrind?
Comment 2 Snark 2010-02-24 12:32:28 UTC
Yes, I can reproduce it, it's pretty easy.

Valgrind says :
==24321== Process terminating with default action of signal 11 (SIGSEGV)
==24321==  Bad permissions for mapped region at address 0xB13A130
==24321==    at 0xAC68890: plugin_info_init (plugin_info.c:112)
==24321==    by 0xAC6C867: goom_init (goom_core.c:83)
==24321==    by 0xAC61C39: gst_goom_init (gstgoom.c:187)
==24321==    by 0x558677E: g_type_create_instance (gtype.c:1674)
==24321==    by 0x556B647: g_object_constructor (gobject.c:1383)
==24321==    by 0x556CA61: g_object_newv (gobject.c:1252)
==24321==    by 0x977AF8F: gst_element_factory_create (gstelementfactory.c:415)
==24321==    by 0x977B7CB: gst_element_factory_make (gstelementfactory.c:482)
==24321==    by 0x97DABEC: _gst_parse_yyparse (grammar.y:601)
==24321==    by 0x97DCB85: _gst_parse_launch (grammar.y:870)
==24321==    by 0x97D1C91: gst_parse_launch_full (gstparse.c:293)
==24321==    by 0x97D1D03: gst_parse_launch (gstparse.c:259)
Comment 3 Tim-Philipp Müller 2010-02-24 13:23:14 UTC
> Valgrind says :
> ==24321== Process terminating with default action of signal 11 (SIGSEGV)
> ==24321==  Bad permissions for mapped region at address 0xB13A130
> ==24321==    at 0xAC68890: plugin_info_init (plugin_info.c:112)
> ==24321==    by 0xAC6C867: goom_init (goom_core.c:83)

so it crashes in: 

   PluginInfo p = { 0, };

? ...
Comment 4 Snark 2010-02-24 17:44:12 UTC
Yes, it does crash at that very line.

Notice that doing the same testing call with the videotest plugin doesn't lead to a crash : only goom has the problem!

Weird, isn't it?
Comment 5 Tim-Philipp Müller 2010-04-29 20:08:35 UTC
Does it still happen with the latest release / current git?
Comment 6 Snark 2010-05-03 12:37:52 UTC
I'm using debian unstable's latest gstreamer0.10-plugins-good (0.10.22-1), and yes I still get a crash. Mysterious...
Comment 7 Tim-Philipp Müller 2010-05-03 17:29:16 UTC
Does it also happen if you use that pipeline in connection with gst-launch-0.10?
Comment 8 Snark 2010-05-03 18:17:27 UTC
No, only in ekiga's plugin... the one I pushed AppSrc&AppSink for...
Comment 9 Tim-Philipp Müller 2010-05-03 19:18:11 UTC
Ok, so what is the easiest/minimal way to reproduce this on a debian sid system then?
Comment 10 Snark 2010-05-03 20:01:41 UTC
1) compile ekiga with --enable-gstreamer ;
2) choose goom as a video input device ;
3) finally connect to the echo test.

There's no problem in video preview : only during a call (and only with goom... using a real webcam or some other source seems to work).
Comment 11 Tim-Philipp Müller 2010-05-03 20:41:50 UTC
Well, I don't seem to be able to comiple ekiga master using the packages in debian sid or experimental, so giving up on that (opal too old it seems).

If you can't reproduce this with gst-launch or a small test program, then chances are it's ekiga's fault.

Please provide a small test program in C (or python, but preferably C) that reproduces this bug.
Comment 12 Tobias Mueller 2010-06-27 22:53:22 UTC
Hm Julien. Do you have any news on this?
Comment 13 Snark 2010-06-28 06:49:41 UTC
I just tested ; the bad news is that I still get a crash -- the good news is that the trace is different and even looks sane!

Let me leave that bug NEEDINFO for now, but I'm hopeful something can be done.
Comment 14 Snark 2010-06-28 07:55:25 UTC
Created attachment 164786 [details]
Trace

Sigh... here is a better trace.

What I saw which had a better look was just warnings about string conversions elsewhere in the code :-/

Could we be hit by a threading issue?
Comment 15 Tim-Philipp Müller 2010-06-28 08:11:34 UTC
Created attachment 164787 [details] [review]
goom: don't allocate 260kB struct on the stack

    PluginInfo is quite a sizeable struct, let's not allocate it on the
    stack, especially not if we're copying it over into another dynamically
    allocated copy anyway.
    
    Possibly fixes #570761.

Any chance you could try this patch?
Comment 16 Snark 2010-06-28 13:52:02 UTC
I tried your patch : the crash disappeared!

Very good!

When will it go out? (ie: be found in distributions)
Comment 17 Tim-Philipp Müller 2010-06-28 14:07:26 UTC
Great, thanks for testing:

commit cf8dddd5c7913c3b80aa2c28c19afaa8a2757f5e
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Mon Jun 28 09:07:58 2010 +0100

    goom: don't allocate 260kB struct on the stack
    
    PluginInfo is quite a sizeable struct, let's not allocate it on the
    stack, especially not if we're copying it over into another dynamically
    allocated copy anyway.
    
    Fixes #570761.

Will be part of the 0.10.24 gst-plugins-good release which should be out in 1-2 weeks or so.  When that will be found in distros depends on the distros.

On a side note, it's a bit surprising you experienced this problem on a normal desktop system (as opposed to an embedded environment with smaller stack sizes). Something up higher in the stack must be allocating lots of stuff on the stack as well, which may or may not cause problems. You might want to look into that too...
Comment 18 Snark 2010-06-28 18:59:00 UTC
Indeed a stack issue is alarming... if only I knew how to debug that :-(