Ugh (a.k.a. GStreamer)

20 views
Skip to first unread message

Scott Peterson

unread,
Jul 9, 2007, 3:52:12 PM7/9/07
to Aaron Bockover, mono-s...@googlegroups.com
OK, after much pain and debugging, GStreamer works with Banshee on Windows. The solution is both elegant and disgusting: in the end I simply needed to alter a URI string passed to native code. Of course a proper error message with mention of the bad URI would be asking too much of GStreamer. It's much more fun to toil for weeks, building GStreamer and then glib and then gtk in Visual Studio so as to debug the problem *cough*cough*sarcasm*cough*. Actually the GStreamer people are really nice but that code desperately needs better error handling.

Anyhoo, another day, another problem in native code. When libbanshee calls back into managed code (for gstreamer callbacks: iterator, statechanged, &c.), everything dies with this: "An unhandled exception of type ' System.AccessViolationException' occurred in gtk-sharp.dll". Here's a bit of the callstack:

     ntdll.dll!7c901010()    
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll ]   
     libgthread-2.0-0.dll!65c41201()    
>    libbanshee.dll!gst_playback_iterate_timeout(GstPlayback * engine=0x0012f29c)  Line 307 + 0xc bytes    C

It barfs under the Mono runtime too, with no additional information. Ideas? This native code is killing me :desperatelaugh:

--
Scott.

Miguel de Icaza

unread,
Jul 11, 2007, 4:10:09 PM7/11/07
to mono-s...@googlegroups.com

Anyhoo, another day, another problem in native code. When libbanshee calls back into managed code (for gstreamer callbacks: iterator, statechanged, &c.), everything dies with this: "An unhandled exception of type ' System.AccessViolationException' occurred in gtk-sharp.dll". Here's a bit of the callstack:

     ntdll.dll!7c901010()    
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll ]   
     libgthread-2.0-0.dll!65c41201()    
>    libbanshee.dll!gst_playback_iterate_timeout(GstPlayback * engine=0x0012f29c)  Line 307 + 0xc bytes    C

It barfs under the Mono runtime too, with no additional information. Ideas? This native code is killing me :desperatelaugh:

This could be caused by the calling conventions on Windows.

Gtk# Makefiles use a script that inserts the CDecl attributes in delegates to fix the signature, see:

gtk-sharp/gapi-cdecl-insert

And see how its used in gtk-sharp/gtk/makefile.win32
 


Scott Peterson

unread,
Jul 12, 2007, 3:07:16 PM7/12/07
to mono-soc-2007
Jonathan Pryor turned me on to a great .NET 2.0 solution: the
[UnmanagedFunctionPointer(CallingConvention.Cdecl)] attribute. I just
slap it on the delegate definitions and it works like a charm.

On Jul 11, 4:10 pm, "Miguel de Icaza" <miguel.de.ic...@gmail.com>
wrote:

Reply all
Reply to author
Forward
0 new messages