[PD] pix_openni crash Pd
Jack
jack at rybn.org
Mon Feb 27 23:35:56 CET 2012
Le 27/02/2012 23:00, Jack a écrit :
> Le 27/02/2012 15:51, IOhannes m zmoelnig a écrit :
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 2012-02-27 15:20, Jack wrote:
>>
>>> I use Ubuntu 11.04, Pd 0.42.6 and Gem 0.93.git fad1264.
>> upgrade Gem to at least "0.93.git 1482ffb1538"
>>
>> and do a complete rebuild of Gem.
>>
>> fgmasd
>> IOhannes
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk9LmGcACgkQkX2Xpv6ydvTHpgCghXseYp2gv0VYyFvtaCKBFH9u
>> ATUAoN73DbawoPq8HzU0MZsWULJf2UcV
>> =/cUU
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
> OK, i upgraded Gem to ver: 0.93.git f1a1841 and now i can render the
> scene without crash.
> But, i can't see anything working there : I get a blue sphere where it
> is write 'gem' and a white rectangle in the top-left corner (even if i
> select 'rgb 1' in [pd properties]).
> If i click on the message 'video_mode' in this subpatch, Pd crash. And
> if i click on 'bang', nothing happens in the console (there is no
> available modes).
Here the output with valgrind :
==16138== HEAP SUMMARY:
==16138== in use at exit: 10,269,587 bytes in 14,507 blocks
==16138== total heap usage: 44,548 allocs, 30,041 frees, 46,723,357
bytes allocated
==16138==
==16138== LEAK SUMMARY:
==16138== definitely lost: 14,663 bytes in 50 blocks
==16138== indirectly lost: 8,291 bytes in 488 blocks
==16138== possibly lost: 1,525 bytes in 56 blocks
==16138== still reachable: 10,245,108 bytes in 13,913 blocks
==16138== suppressed: 0 bytes in 0 blocks
==16138== Rerun with --leak-check=full to see details of leaked memory
==16138==
==16138== For counts of detected and suppressed errors, rerun with: -v
==16138== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
==16139==
==16139== HEAP SUMMARY:
==16139== in use at exit: 10,269,587 bytes in 14,507 blocks
==16139== total heap usage: 44,548 allocs, 30,041 frees, 46,723,357
bytes allocated
==16139==
==16139== LEAK SUMMARY:
==16139== definitely lost: 14,663 bytes in 50 blocks
==16139== indirectly lost: 8,291 bytes in 488 blocks
==16139== possibly lost: 1,525 bytes in 56 blocks
==16139== still reachable: 10,245,108 bytes in 13,913 blocks
==16139== suppressed: 0 bytes in 0 blocks
==16139== Rerun with --leak-check=full to see details of leaked memory
==16139==
==16139== For counts of detected and suppressed errors, rerun with: -v
==16139== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
==16140==
==16140== HEAP SUMMARY:
==16140== in use at exit: 10,269,587 bytes in 14,507 blocks
==16140== total heap usage: 44,548 allocs, 30,041 frees, 46,723,357
bytes allocated
==16140==
==16140== LEAK SUMMARY:
==16140== definitely lost: 14,663 bytes in 50 blocks
==16140== indirectly lost: 8,291 bytes in 488 blocks
==16140== possibly lost: 1,525 bytes in 56 blocks
==16140== still reachable: 10,245,108 bytes in 13,913 blocks
==16140== suppressed: 0 bytes in 0 blocks
==16140== Rerun with --leak-check=full to see details of leaked memory
==16140==
==16140== For counts of detected and suppressed errors, rerun with: -v
==16140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
==16141==
==16141== HEAP SUMMARY:
==16141== in use at exit: 10,269,587 bytes in 14,507 blocks
==16141== total heap usage: 44,548 allocs, 30,041 frees, 46,723,357
bytes allocated
==16141==
==16141== LEAK SUMMARY:
==16141== definitely lost: 14,663 bytes in 50 blocks
==16141== indirectly lost: 8,291 bytes in 488 blocks
==16141== possibly lost: 1,525 bytes in 56 blocks
==16141== still reachable: 10,245,108 bytes in 13,913 blocks
==16141== suppressed: 0 bytes in 0 blocks
==16141== Rerun with --leak-check=full to see details of leaked memory
==16141==
==16141== For counts of detected and suppressed errors, rerun with: -v
==16141== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
==16122== Invalid read of size 4
==16122== at 0xA6D106A: xnSetMapOutputMode (in /usr/lib/libOpenNI.so)
==16122== by 0xA677432: pix_openni::VideoModeMess(int, _atom*)
(XnCppWrapper.h:2717)
==16122== by 0x41EFFFFF: ???
==16122== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16122==
==16122==
==16122== Process terminating with default action of signal 11 (SIGSEGV)
==16122== Access not within mapped region at address 0x0
==16122== at 0xA6D106A: xnSetMapOutputMode (in /usr/lib/libOpenNI.so)
==16122== by 0xA677432: pix_openni::VideoModeMess(int, _atom*)
(XnCppWrapper.h:2717)
==16122== by 0x41EFFFFF: ???
==16122== If you believe this happened as a result of a stack
==16122== overflow in your program's main thread (unlikely but
==16122== possible), you can try to increase the size of the
==16122== main thread stack using the --main-stacksize= flag.
==16122== The main thread stack size used in this run was -1.
==16122==
==16122== HEAP SUMMARY:
==16122== in use at exit: 66,721,759 bytes in 50,018 blocks
==16122== total heap usage: 221,732 allocs, 171,714 frees, 364,868,787
bytes allocated
==16122==
==16122== LEAK SUMMARY:
==16122== definitely lost: 17,149 bytes in 61 blocks
==16122== indirectly lost: 10,576 bytes in 607 blocks
==16122== possibly lost: 981,116 bytes in 8,399 blocks
==16122== still reachable: 65,712,918 bytes in 40,951 blocks
==16122== suppressed: 0 bytes in 0 blocks
==16122== Rerun with --leak-check=full to see details of leaked memory
==16122==
==16122== For counts of detected and suppressed errors, rerun with: -v
==16122== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2653 from 11)
socket receive error: Connection reset by peer (104)
Erreur de segmentation
++
Jack
> I miss something ?
> One comment : it is very strange to see two [gemhead] connected
> directly in [pix_openni]. Is there a meaning ?
> Thanx for help.
> ++
>
> Jack
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120227/d157fa18/attachment-0001.htm>
More information about the Pd-list
mailing list