hi all,
pix_opencv seems to not work with GEM: ver: 0.93.git 12c184c whereas it works with GEM: ver: 0.93.SVN rev4516
"doesn't work" means it crashes (seg fault) when an image comes in i don't test all objects but a lot of them suffer from this it crashes both on color or gray images
does anyone can reproduce this and/or have an idea on how to fix it ?
best
antoine
hi,
pix_opencv still crashes with GEM from git after 0.93.3 tag two weeks later and some time spend to figure out which commit broke the things i need help i can't figure out what happen in the gem code since the 11th of november 2011 that can crash pix_opencv moreover i don't know how to investigate through all the commits to identify the cause easily
any advice would be great...
thanks in advance
antoine
On 02/13/12 22:30, Antoine Villeret wrote:
hi,
pix_opencv still crashes with GEM from git after 0.93.3 tag two weeks later and some time spend to figure out which commit broke the things i need help i can't figure out what happen in the gem code since the 11th of november 2011 that can crash pix_opencv moreover i don't know how to investigate through all the commits to identify the cause easily
any advice would be great...
"git bisect" is a great tool for finding a regressions that appeared "somewhen" using binary search. since it is a crash, you could even write a simple test, that fully automates the bughunt. (note: the crash makes it simpler because of Pd, not because of 'git bisect')
fgmar IOhannes
hi,
thanks for that, I've done severals tests. One with bisect and it finds with its dichotomy method that commit af05802ced7516d008f54b97d7a2a628e8b84a64 is the last working version with pix_opencv between 0.93 tag and master You can find the bisect log in attachment.
the other test i made is to start from master and go back through the rev-list to 0.93 commit by commit until i found a working version the first one I found is : 4b1ec61b29ce82e5b20eb67bc7900cf6dd54aadb this test was made with a script (see attachment)
moreover i can go forward from this working point until commit 5b62940b3a260d814c3eb4f9791e13c9c0539ec5 and make pix_opencv working but when i'm going in the reverse way it crashes and the first working commit i found is af05802ced7516d008f54b97d7a2a628e8b84a64 (the same as bisect found) but i didn't test all...
git diff says me a lot of things but i can't understand where the issue with pix_opencv is
i hope thoses informations are enough to quickly fix the issue cause it freaks me out !
cheers
antoine
On 02/16/12 03:21, Antoine Villeret wrote:
i hope thoses informations are enough to quickly fix the issue cause it freaks me out !
unfortunately not. i'm pretty sure that the revision you found with "git bisect" is totally unrelated to the problem, which might indicate some memory corruption.
would you mind using some debugging beasts, like gdb (to get a backtrace) and valgrind (to check for memory corruption)?
oh, and what OS ar you on?
fgm,asdr IOhannes
On 02/16/12 17:28, IOhannes m zmölnig wrote:
On 02/16/12 03:21, Antoine Villeret wrote:
i hope thoses informations are enough to quickly fix the issue cause it freaks me out !
unfortunately not. i'm pretty sure that the revision you found with "git bisect" is totally unrelated to the problem, which might indicate some memory corruption.
would you mind using some debugging beasts, like gdb (to get a backtrace) and valgrind (to check for memory corruption)?
hmm, i checked and i can indeed confirm the problem. i think this is the same bug i currently experience with pdgst, that crashes (that is the pdgst/Gem bindings) on my 64bit system, but not on a 32bit system (iirc).
fgamdsr IOhannes
On 02/16/12 17:51, IOhannes m zmölnig wrote:
hmm, i checked and i can indeed confirm the problem. i think this is the same bug i currently experience with pdgst, that crashes (that is the pdgst/Gem bindings) on my 64bit system, but not on a 32bit system (iirc).
ha, i think i found the culprit. Gem is compiled with "-mms-bitfields" (which is important on w32 if you want to use e.g. Gem compiled with MinGW on a Pd compiled with MSVC), and pix_opencv is not (and neither is pdgst/Gem)
adding "-mms-bitfields" to the pix_opencv Makefile fixed the problem, but the real fix will be to remove "-mms-bitfields" from Gem on non-w32.
fg asdrm IOhannes
wow ! congratulations, it works !
you are so quick that i can't compile and test it between your last two emails ! i always believe that you can fix it quicker than I ! ;-)
thanks again !
btw, it was crashing both on Ubuntu 10.04 32bit and Mint 12 (Ubuntu 11.10) 64 bit all are fixed for pix_opencv
pdgst is working on 32 bit but i got an undefined symbol error on 64 bit : pdgst.pd_linux: undefined symbol: g_object_get_property
and I also noticed that making Gem as a normal user lead to an error :
Assembler messages: Fatal error: can't create .libs/gem_modelOBJ_la-modelOBJ.o: Permission denied make[2]: *** [gem_modelOBJ_la-modelOBJ.lo] Error 1 make[2]: Leaving directory `/home/antoine/pd/externals/Gem/plugins/modelOBJ'
and i have to make it as su (sudo make) it's a minor issue but could make scripts failed on automatic installation
anyway, thanks a lot again for the work
antoine
Awesome work here! Congrats, Ricardo.
2012/2/16 Antoine Villeret antoine.villeret@gmail.com:
wow ! congratulations, it works !
you are so quick that i can't compile and test it between your last two emails ! i always believe that you can fix it quicker than I ! ;-)
thanks again !
btw, it was crashing both on Ubuntu 10.04 32bit and Mint 12 (Ubuntu 11.10) 64 bit all are fixed for pix_opencv
pdgst is working on 32 bit but i got an undefined symbol error on 64 bit : pdgst.pd_linux: undefined symbol: g_object_get_property
and I also noticed that making Gem as a normal user lead to an error :
Assembler messages: Fatal error: can't create .libs/gem_modelOBJ_la-modelOBJ.o: Permission denied make[2]: *** [gem_modelOBJ_la-modelOBJ.lo] Error 1 make[2]: Leaving directory `/home/antoine/pd/externals/Gem/plugins/modelOBJ'
and i have to make it as su (sudo make) it's a minor issue but could make scripts failed on automatic installation
anyway, thanks a lot again for the work
antoine
-- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/2/16 IOhannes m zmölnig zmoelnig@iem.at
On 02/16/12 20:20, IOhannes m zmölnig wrote:
but the real fix will be to remove "-mms-bitfields" from Gem on non-w32.
i pushed a fix to Gem which seems to fix the problem
fgnasdr
IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-16 22:28, Antoine Villeret wrote:
pdgst is working on 32 bit but i got an undefined symbol error on 64 bit : pdgst.pd_linux: undefined symbol: g_object_get_property
seems like a problem with gstreamer/glib...
and I also noticed that making Gem as a normal user lead to an error :
Assembler messages: Fatal error: can't create .libs/gem_modelOBJ_la-modelOBJ.o: Permission denied
i think you have leftovers from a previous build run as a different user (probably root).
something like: $ chown -R antoine . $ make
should do the trick (until next time you decide to run "sudo make")
hmst IOhannes
On 02/16/2012 02:20 PM, IOhannes m zmölnig wrote:
On 02/16/12 17:51, IOhannes m zmölnig wrote:
hmm, i checked and i can indeed confirm the problem. i think this is the same bug i currently experience with pdgst, that crashes (that is the pdgst/Gem bindings) on my 64bit system, but not on a 32bit system (iirc).
ha, i think i found the culprit. Gem is compiled with "-mms-bitfields" (which is important on w32 if you want to use e.g. Gem compiled with MinGW on a Pd compiled with MSVC), and pix_opencv is not (and neither is pdgst/Gem)
adding "-mms-bitfields" to the pix_opencv Makefile fixed the problem, but the real fix will be to remove "-mms-bitfields" from Gem on non-w32.
-mms-bitfields should really only be used on Win32, unless you are doing something really weird, or building for Win32 on GNU/Linux+MinGW.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-16 23:00, Hans-Christoph Steiner wrote:
-mms-bitfields should really only be used on Win32, unless you are doing something really weird, or building for Win32 on GNU/Linux+MinGW.
well yes. what i don't really understand is, why gcc on linux (i'm not talking about a cross-compiler like i686-w64-mingw32-gcc that runs on linux but really builds w32 binaries, but instead about a native compiler that produces binaries for linux) provides and uses the "-mms-bitfields" flag at all. what are the possible uses of ms-bitfields on linux?
fgmar IOhannes
On Feb 17, 2012, at 4:27 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-16 23:00, Hans-Christoph Steiner wrote:
-mms-bitfields should really only be used on Win32, unless you are doing something really weird, or building for Win32 on GNU/Linux+MinGW.
well yes. what i don't really understand is, why gcc on linux (i'm not talking about a cross-compiler like i686-w64-mingw32-gcc that runs on linux but really builds w32 binaries, but instead about a native compiler that produces binaries for linux) provides and uses the "-mms-bitfields" flag at all. what are the possible uses of ms-bitfields on linux?
I think there are no uses of running ms-bitfields code on GNU/Linux. But the gcc on some distros includes things like -mms-bitfields and -mandroid to build for those platforms without using a cross-compiler.
.hc
----------------------------------------------------------------------------
kill your television
-
Antoine Villeret -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ricardo Fabbri