[gst-devel] Segmentation fault in g_type_check_instance_cast

[Joshua Lamorie]

Well, I have isolated the problem to be something in the way that
GST_TYPE_APP_SRC returns a reference to the g_type.  For some reason,
the way that I've built my application (on a 64-bit system) is mixing in
a few 32-bit references, so instead of returning 0x7fff12345678 it
returns 0x12345678 and a segfault occurs.

I've rebuilt my code on a 'pure' 32-bit system, and everything appears
to be okay.

Thanks

Joshua

On Wed, 2010-12-15 at 13:28 -0500, Joshua Lamorie wrote: 
> Gidday there,
> 
> I'm having some issues with some code that runs fine as a 'standalone'
> application, but when I put it into a thread spawned by another
> application it has a segfault.
> 
> The following is from GDB:
> 
> [Switching to Thread 0x7ffff106f710 (LWP 4780)]
> IA__g_type_check_instance_cast (type_instance=0x7fffe4008030
> [GstAppSrc], iface_type=3825213056) at gtype.c:3973
> 3973   check = is_instantiatable && iface && type_node_conforms_to_U
> (node, iface, TRUE, FALSE);
> 
> (gdb) bt
> #0  IA__g_type_check_instance_cast (type_instance=0x7fffe4008030
> [GstAppSrc], iface_type=3825213056) at gtype.c:3973
> #1  0x00007ffff7b3fb64 in ESMRTPThreadMain (pArg=0x7fffec0052d0) at
> RTPSourcePlugin.c:283
> #2  0x000000346fe64e84 in g_thread_create_proxy (data=0x7fffec005290) at
> gthread.c:1893
> #3  0x000000346de07761 in start_thread (arg=0x7ffff106f710) at
> pthread_create.c:301
> #4  0x000000346d2e14fd in clone ()
> at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> 
> 
> Here's some pseudo code of the overall system.
> 
> 1) Main C++ application loads and initializes itself.
> 2) Opens a .so containing a few extern C functions/symbols.
> 3) Calls an Init() function from the .so (which calls gst_init())
> 4) Calls pthread_create() and sits on an accept() call.
> 4.1) The accept() returns and a message is read by the C++ app/thread.
> 4.2) This then calls an Execute() function from the .so.
> 4.3) The Execute() method creates a thread (either pthread_create or
> g_thread_create).
> 4.3.1) The newly created thread is pretty much copy and pasted from a
> functional 'standalone' gstreamer application and initializes itself.
> 4.3.2) During a call (cast) to GST_APP_SRC(GstElement *) a segfault
> occurs somewhere within the inlined functions.
> 
> I've put this in gdb and it appears that all of the input arguments are
> non-NULL, but deep within the inlined functions I saw some references to
> what appear to be global locking variables.  I'm concerned that my
> initialization doesn't quite match the standalone case, but I can't
> quite figure out what is going on 'behind-the-curtain' in the standalone
> case that is different from my multi-threaded example.
> 
> Standalone code:
> 
> GMainLoop *loop;
> int main(int iArgc, char * ppcArgv[]) {
>   GstElement * poAppSrc;
>   GstElement * poPipeline;
>   /* ... snip ... */
>   /* initialize gstreamer */
>   gst_init(NULL,NULL);
>   loop = g_main_loop_new (NULL, TRUE);
>   poPipeline = gst_pipeline_new("ESMPipeline");
>   poAppSrc = gst_element_factory_make("appsrc", NULL);
>   gst_app_src_set_stream_type(GST_APP_SRC(poAppSrc),
>     GST_APP_STREAM_TYPE_STREAM);
>   /* ... snip ... */
> }
> 
> Thread code:
> 
> void * ESMRTPThreadMain(void * pArg) {
>   GstElement * poPipeline = NULL;
>   GstElement * poAppSrc = NULL;
>   /* ... snip ... */
>   poPipeline = gst_pipeline_new("ESMPipeline");
>   poAppSrc = gst_element_factory_make("appsrc",NULL);
>   if (poAppSrc == NULL) {
>     printf("Problem generating appsrc element\n");
>     return(NULL);
>   }
>   /* set stream type */
>   gst_app_src_set_stream_type(GST_APP_SRC(poAppSrc),
>     GST_APP_STREAM_TYPE_STREAM);
>   /* ... snip ... */
> }
> 
> So what am I doing wrong in the initialization to cause the segfault?
> 
> Thanks in advance.
> 

-- 
Joshua Lamorie, P. Eng.
Chief Engineer
Xiphos Technologies Inc.
 
Email: jpl at xiphos.ca
Phone: +1 (514) 847-9474 ext. 227
Fax: +1 (514) 847-9474

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you have received this in error, please contact the sender
and delete this communication and any copy immediately. Thank you.