[Mono-dev] weird wrapper crash using wrappers in mono..#1 0x0098e4d6 in nanosleep () from /lib/libpthread.so.0...blablabla
Euan MacInnes
euan_macinnes at hotmail.com
Fri Sep 3 07:54:15 EDT 2010
it depends on timing as well, are these in different threads in Mono? 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.
Cheers,
Euan.
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> 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
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: Thu, 2 Sep 2010 22:36:49 -0400
CC: mono-devel-list at lists.ximian.com
El 02-09-2010, a las 21:40, Euan MacInnes <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
To: 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
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/4d6604f1/attachment.html
More information about the Mono-devel-list
mailing list