[Mono-dev] weird wrapper crash using wrappers in mono..#1 0x0098e4d6 in nanosleep () from /lib/libpthread.so.0...blablabla
buhochilenoi@gmail.com
buhochileno at gmail.com
Fri Sep 3 09:17:24 EDT 2010
On 09/03/2010 07:54 AM, Euan MacInnes wrote:
> it depends on timing as well, are these in different threads in Mono?
one single mono thread...just "main"...
> maybe need to single-threaded open the device once for ffmpeg, then
> again for phidgets. Play around with the start order as well, maybe
> one is keeping the device open and the other isn't, assuming the order
> of initialisation is different between C# and C.
yeap, I'm playing with that..
>
> Cheers,
>
> Euan.
>
Thanks
Mauricio
> ------------------------------------------------------------------------
> From: buhochileno at gmail.com
> To: euan_macinnes at hotmail.com
> Subject: Re: [Mono-dev] weird wrapper crash using wrappers in mono..#1
> 0x0098e4d6 in nanosleep () from /lib/libpthread.so.0...blablabla
> Date: Fri, 3 Sep 2010 07:50:22 -0400
> CC: mono-devel-list at lists.ximian.com
>
>
>
> El 03-09-2010, a las 7:22, Euan MacInnes <euan_macinnes at hotmail.com
> <mailto:euan_macinnes at hotmail.com>> escribi¨®:
>
> interesting then that it's failing both on the av_registerdevice
> line and/or device.open. Sounds like they're both trying to open
> the same device and it's failing as it can't be opened twice.
>
> Yeap, may be some USBish thing, since probably avregister_device do
> some USB scan/check and phidgets devices are also USB...
> One another thing to add weirdness to all this, is that this was
> working Ok on Fedora 10 to a certain point, then in some moment, the
> ffmpeg guys (or RPM packagers), beging to provide libdc1394 as a
> separated package/lib (previously was included in ffmpeg-libs
> package), and from that moment the problem show up. Currently if I
> remove libdc1394xxxzzyy.RPM from my sys and both code are more happy
> together (not entirely becouse ffmpeg beging to act weird since it
> miss those bits, the libdc1394 need to be removen by force "--nodeps"
> to avoid uninstall the hole ffmpeg packages and some other softwares).
>
> Weird, weird...
>
> The thing that I miss here is how mono runtime is involve in all this,
> since as I mention playing with phidget + ffmpeg code in a pure C
> scenario don't make any problem...
>
>
> Regards,
>
> Mauricio
>
>
> ------------------------------------------------------------------------
> From: buhochileno at gmail.com <mailto:buhochileno at gmail.com>
> To: euan_macinnes at hotmail.com <mailto:euan_macinnes at hotmail.com>
> Subject: Re: [Mono-dev] weird wrapper crash using wrappers in
> mono..#1 0x0098e4d6 in nanosleep () from
> /lib/libpthread.so.0...blablabla
> Date: Thu, 2 Sep 2010 22:36:49 -0400
> CC: mono-devel-list at lists.ximian.com
> <mailto:mono-devel-list at lists.ximian.com>
>
>
>
> El 02-09-2010, a las 21:40, Euan MacInnes
> <euan_macinnes at hotmail.com <mailto:euan_macinnes at hotmail.com>>
> escribi¨®:
>
> The first suspicious thing in the output is the pixel format
> of -1 and the width/height of 0. This should not be the case
> for the sws to get it's correct pixel conversion context.
>
> Alos, the merged C# program seems threaded as you're getting a
> stack trace halfway through the FFMpeg, with presumably some
> phidgets calls mixed in. FFmpeg is constantly creating memory
> buffers and dumping into that, if something from phidgets is
> leaking into memory, that can cause FFmpeg to trip.
>
> The first thing to then do here is to work out which line of
> code is causing the problem, debug statements to narrow that
> down, and then look at what's happening before it.
>
> Right, the ffmpeg part is easy as we know the wrapper ;-) , the
> ofending line (if is a ffmpeg fault) is av_registerdevice,
> commenting that one and all works. From phidgets perspective is
> the device.open() call, comnenting that and all works. Sadly I
> don't have the source code of that lib, I need to ask to the
> company if I can get the sourcecode to do a better debug..
>
> Any other souspicios thing on the mono front in the meantime?, may
> be you guys see some simillar issue arround some other wrappers
> convinations..?
>
>
> Thank Euan!, talk to you soon..
>
> Cheers!
>
>
>
>
> Date: Thu, 2 Sep 2010 18:51:43 -0400
> From: buhochileno at gmail.com <mailto:buhochileno at gmail.com>
> To: mono-devel-list at lists.ximian.com
> <mailto:mono-devel-list at lists.ximian.com>
> Subject: [Mono-dev] weird wrapper crash using wrappers in
> mono..#1 0x0098e4d6 in nanosleep () from
> /lib/libpthread.so.0...blablabla
>
> Hi guys,
>
> This is by far the most weird thing that happend to me using mono, so be
> patience with me trying to explaining..and is not easy to provide a test
> case--
>
> We have a C# ffmpeg wrapper (nothing to fancy, just takeing frames from
> media) and we also use Phidgets devices (also with a wrapper of course,
> http://www.phidgets.com), using both in a separated way with mono 2.4 or
> last mono 2.6 (linux 32bits and this happen on fedora 10,11,12, don't
> know about 13...) and all works ok. Also, mixing ffmpeg C code plus
> phidget C code into a sample program and also all good with the world
> (all in C in this case, no wrapper).
>
> But here the really, really weird thing, mixing both in a C# program and
> running with mono on linux (.NET on Windows also ok) and all goes to
> hell!!, the problems seems related to ffmpeg (may be compilation memory
> options or something else?), since in the stacktrace some messages
> mention "libdc1394.so" (beside a bunch of other libs), but the weird
> thing is that if I remove the "phidget" code in the C# sample and no
> problem with libdc1394 or any other ffmpeg wrapper realted call. Also
> removing the ffmpeg wrapper related code from thesample and the C#
> phidget code start to work again without problems...And as I mention,
> both code doing just C code and all works nicely together...so mono is
> on the equation in some weird way...
>
> I have a kind of reduce test, but you are going to need to compile some
> libs to do a proper test and also I be forced to send you the phidget
> libs (which I don't know if it breakes any licence, or you have to
> download the lib from phidgets website..), so a test on your side
> involve some work that I don't know if you have the time or are will to
> do it...
>
> So, I'm lost about where to start to look or do to fix the issue and I
> prefer to ask here before to fill a hard to reproduce bug ....So, here
> is the complete stacktrace in case you see anything souspicious or may
> be I can do something to give you more proper info....Thanks in advance
> guys!!
>
> Mauricio
>
> ISE.Media.FFmpeg: opening input file
> Input #0, avi, from '/home/buho/Desktop/War3-Movie-Trailer.avi':
> Duration: 00:00:29.99, start: 0.000000, bitrate: 1040 kb/s
> Stream #0.0: Video: mpeg4, yuv420p, 800x340 [PAR 1:1 DAR 40:17], 24
> tbr, 24 tbn, 30k tbc
> Stream #0.1: Audio: mp3, 44100 Hz, 2 channels, s16, 128 kb/s
> ISE.Media.FFmpeg: Found 2 Streams
> ISE.Media.FFmpeg: Processing Stream 0...
> ISE.Media.FFmpeg: Video Stream...
> ISE.Media.FFmpeg: Processing Stream 1...
> ISE.Media.FFmpeg: Audio Stream...
> CONTEXT ID : 0...
>
> Native stacktrace:
>
> ISE.Media.FFmpeg: Setting Up Video Frame
> ISE.Media.FFmpeg: Pixel Format: fmt: -1 w: 0 h: 0
> ISE.Media.FFmpeg: Frame buffer size: 816000
> [swscaler @ 0x9254a00]No accelerated colorspace conversion found.
> ISE.Media.FFmpeg: Got sws context
> ISE.Media.FFmpeg: Video Frames established
> /usr/bin/mono() [0x80c6cbb]
> /usr/bin/mono() [0x805b058]
> [0xb77f040c]
> /usr/lib/libdc1394.so.22(register_platform+0x79) [0xb6a22e79]
> /usr/lib/libdc1394.so.22(usb_init+0x32) [0xb6a3c782]
> /usr/lib/libphidget21.so(CUSBBuildList+0x2c) [0xb632fd6c]
> /usr/lib/libphidget21.so(CPhidgetManager_poll+0xee) [0xb63226be]
> /usr/lib/libphidget21.so(CentralThreadFunction+0x45) [0xb632fc95]
> /lib/libpthread.so.0() [0x986ab5]
> /lib/libc.so.6(clone+0x5e) [0x8b183e]
>
> Debug info from gdb:
>
> OutputWidth = 800, OutputHeight = 340
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 0
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 417
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 834
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 1252
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 1668
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: AUDIO packet 417
> ISE.Media.FFmpeg: Decoding 192001 153002912 2086
> ISE.Media.FFmpeg: Decoded 417 4608
> ISE.Media.FFmpeg: Freeing RGB Image
> ISE.Media.FFmpeg: Freeing YUV Frame
> ISE.Media.FFmpeg: Closing the Codec
> ISE.Media.FFmpeg: Closing input file
> ISE.Media.FFmpeg: Decoder context destroyed
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb62dfb70 (LWP 3638)]
> [New Thread 0xb6e60b70 (LWP 3637)]
> [New Thread 0xb77d7b70 (LWP 3636)]
> 0x0819ba09 in ?? ()
> 4 Thread 0xb77d7b70 (LWP 3636) 0xb77f0424 in __kernel_vsyscall ()
> 3 Thread 0xb6e60b70 (LWP 3637) 0xb77f0424 in __kernel_vsyscall ()
> 2 Thread 0xb62dfb70 (LWP 3638) 0xb77f0424 in __kernel_vsyscall ()
> * 1 Thread 0xb77c76f0 (LWP 3634) 0x0819ba09 in ?? ()
>
> Thread 4 (Thread 0xb77d7b70 (LWP 3636)):
> #0 0xb77f0424 in __kernel_vsyscall ()
> #1 0x0098e4d6 in nanosleep () from /lib/libpthread.so.0
> #2 0x081a33a8 in ?? ()
> #3 0x00986ab5 in start_thread () from /lib/libpthread.so.0
> #4 0x008b183e in clone () from /lib/libc.so.6
>
> Thread 3 (Thread 0xb6e60b70 (LWP 3637)):
> #0 0xb77f0424 in __kernel_vsyscall ()
> #1 0x0098cf85 in sem_wait@@GLIBC_2.1 () from /lib/libpthread.so.0
> #2 0x0812a961 in ?? ()
> #3 0x0814f1ab in ?? ()
> #4 0x081bff62 in ?? ()
> #5 0x081de568 in ?? ()
> #6 0x00986ab5 in start_thread () from /lib/libpthread.so.0
> #7 0x008b183e in clone () from /lib/libc.so.6
>
> Thread 2 (Thread 0xb62dfb70 (LWP 3638)):
> #0 0xb77f0424 in __kernel_vsyscall ()
> #1 0x0098dcfb in read () from /lib/libpthread.so.0
> #2 0x080c6e56 in ?? ()
> #3 0x0805b058 in ?? ()
> #4 <signal handler called>
> #5 0xb6a22e79 in register_platform () from /usr/lib/libdc1394.so.22
> #6 0xb6a3c782 in usb_init () from /usr/lib/libdc1394.so.22
> #7 0xb632fd6c in CUSBBuildList (curList=<value optimized out>)
> at linux/cusblinux.c:287
> #8 0xb63226be in CPhidgetManager_poll () at cphidgetmanager.c:236
> #9 0xb632fc95 in CentralThreadFunction (lpdwParam=<value optimized out>)
> at cthread.c:197
> #10 0x00986ab5 in start_thread () from /lib/libpthread.so.0
> #11 0x008b183e in clone () from /lib/libc.so.6
>
> Thread 1 (Thread 0xb77c76f0 (LWP 3634)):
> #0 0x0819ba09 in ?? ()
> #1 0x08193458 in ?? ()
> #2 0x081942cc in ?? ()
> #3 0x0819487a in mono_class_init ()
> #4 0x08075235 in ?? ()
> #5 0x0805f0c0 in ?? ()
> #6 0x0806089a in ?? ()
> #7 0x080d0607 in ?? ()
> #8 0xb77df066 in ?? ()
> #9 0xbfb3dcb8 in ?? ()
> #10 0xb7235842 in ?? ()
> #11 0x091e2ed4 in ?? ()
> #12 0x00000000 in ?? ()
>
> =================================================================
> Got a SIGSEGV while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =================================================================
>
> bash: line 1: 3634 Aborted (core dumped) /usr/bin/mono
> --debug
> "/home/buho/Desktop/PhidgetsLidc1394Crashtest/test/test/bin/Debug/test.exe"
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list Mono-devel-list at lists.ximian.com
> <mailto:Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100903/a632c881/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buhochileno.vcf
Type: text/x-vcard
Size: 396 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100903/a632c881/attachment-0001.vcf
More information about the Mono-devel-list
mailing list