<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Le 27/02/2012 23:00, Jack a écrit :
<blockquote cite="mid:4F4BFCFC.10108@rybn.org" type="cite">
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
Le 27/02/2012 15:51, IOhannes m zmoelnig a écrit :
<blockquote cite="mid:4F4B986A.2010404@iem.at" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2012-02-27 15:20, Jack wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I use Ubuntu 11.04, Pd 0.42.6 and Gem 0.93.git fad1264.
</pre>
</blockquote>
<pre wrap="">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 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAk9LmGcACgkQkX2Xpv6ydvTHpgCghXseYp2gv0VYyFvtaCKBFH9u
ATUAoN73DbawoPq8HzU0MZsWULJf2UcV
=/cUU
-----END PGP SIGNATURE-----
</pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
OK, i upgraded Gem to ver: 0.93.git f1a1841 and now i can render
the scene without crash.<br>
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]).<br>
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).<br>
</blockquote>
<br>
Here the output with valgrind :<br>
<br>
==16138== HEAP SUMMARY:<br>
==16138== in use at exit: 10,269,587 bytes in 14,507 blocks<br>
==16138== total heap usage: 44,548 allocs, 30,041 frees,
46,723,357 bytes allocated<br>
==16138== <br>
==16138== LEAK SUMMARY:<br>
==16138== definitely lost: 14,663 bytes in 50 blocks<br>
==16138== indirectly lost: 8,291 bytes in 488 blocks<br>
==16138== possibly lost: 1,525 bytes in 56 blocks<br>
==16138== still reachable: 10,245,108 bytes in 13,913 blocks<br>
==16138== suppressed: 0 bytes in 0 blocks<br>
==16138== Rerun with --leak-check=full to see details of leaked
memory<br>
==16138== <br>
==16138== For counts of detected and suppressed errors, rerun with:
-v<br>
==16138== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)<br>
==16139== <br>
==16139== HEAP SUMMARY:<br>
==16139== in use at exit: 10,269,587 bytes in 14,507 blocks<br>
==16139== total heap usage: 44,548 allocs, 30,041 frees,
46,723,357 bytes allocated<br>
==16139== <br>
==16139== LEAK SUMMARY:<br>
==16139== definitely lost: 14,663 bytes in 50 blocks<br>
==16139== indirectly lost: 8,291 bytes in 488 blocks<br>
==16139== possibly lost: 1,525 bytes in 56 blocks<br>
==16139== still reachable: 10,245,108 bytes in 13,913 blocks<br>
==16139== suppressed: 0 bytes in 0 blocks<br>
==16139== Rerun with --leak-check=full to see details of leaked
memory<br>
==16139== <br>
==16139== For counts of detected and suppressed errors, rerun with:
-v<br>
==16139== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)<br>
==16140== <br>
==16140== HEAP SUMMARY:<br>
==16140== in use at exit: 10,269,587 bytes in 14,507 blocks<br>
==16140== total heap usage: 44,548 allocs, 30,041 frees,
46,723,357 bytes allocated<br>
==16140== <br>
==16140== LEAK SUMMARY:<br>
==16140== definitely lost: 14,663 bytes in 50 blocks<br>
==16140== indirectly lost: 8,291 bytes in 488 blocks<br>
==16140== possibly lost: 1,525 bytes in 56 blocks<br>
==16140== still reachable: 10,245,108 bytes in 13,913 blocks<br>
==16140== suppressed: 0 bytes in 0 blocks<br>
==16140== Rerun with --leak-check=full to see details of leaked
memory<br>
==16140== <br>
==16140== For counts of detected and suppressed errors, rerun with:
-v<br>
==16140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)<br>
==16141== <br>
==16141== HEAP SUMMARY:<br>
==16141== in use at exit: 10,269,587 bytes in 14,507 blocks<br>
==16141== total heap usage: 44,548 allocs, 30,041 frees,
46,723,357 bytes allocated<br>
==16141== <br>
==16141== LEAK SUMMARY:<br>
==16141== definitely lost: 14,663 bytes in 50 blocks<br>
==16141== indirectly lost: 8,291 bytes in 488 blocks<br>
==16141== possibly lost: 1,525 bytes in 56 blocks<br>
==16141== still reachable: 10,245,108 bytes in 13,913 blocks<br>
==16141== suppressed: 0 bytes in 0 blocks<br>
==16141== Rerun with --leak-check=full to see details of leaked
memory<br>
==16141== <br>
==16141== For counts of detected and suppressed errors, rerun with:
-v<br>
==16141== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)<br>
==16122== Invalid read of size 4<br>
==16122== at 0xA6D106A: xnSetMapOutputMode (in
/usr/lib/libOpenNI.so)<br>
==16122== by 0xA677432: pix_openni::VideoModeMess(int, _atom*)
(XnCppWrapper.h:2717)<br>
==16122== by 0x41EFFFFF: ???<br>
==16122== Address 0x0 is not stack'd, malloc'd or (recently) free'd<br>
==16122== <br>
==16122== <br>
==16122== Process terminating with default action of signal 11
(SIGSEGV)<br>
==16122== Access not within mapped region at address 0x0<br>
==16122== at 0xA6D106A: xnSetMapOutputMode (in
/usr/lib/libOpenNI.so)<br>
==16122== by 0xA677432: pix_openni::VideoModeMess(int, _atom*)
(XnCppWrapper.h:2717)<br>
==16122== by 0x41EFFFFF: ???<br>
==16122== If you believe this happened as a result of a stack<br>
==16122== overflow in your program's main thread (unlikely but<br>
==16122== possible), you can try to increase the size of the<br>
==16122== main thread stack using the --main-stacksize= flag.<br>
==16122== The main thread stack size used in this run was -1.<br>
==16122== <br>
==16122== HEAP SUMMARY:<br>
==16122== in use at exit: 66,721,759 bytes in 50,018 blocks<br>
==16122== total heap usage: 221,732 allocs, 171,714 frees,
364,868,787 bytes allocated<br>
==16122== <br>
==16122== LEAK SUMMARY:<br>
==16122== definitely lost: 17,149 bytes in 61 blocks<br>
==16122== indirectly lost: 10,576 bytes in 607 blocks<br>
==16122== possibly lost: 981,116 bytes in 8,399 blocks<br>
==16122== still reachable: 65,712,918 bytes in 40,951 blocks<br>
==16122== suppressed: 0 bytes in 0 blocks<br>
==16122== Rerun with --leak-check=full to see details of leaked
memory<br>
==16122== <br>
==16122== For counts of detected and suppressed errors, rerun with:
-v<br>
==16122== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2653
from 11)<br>
socket receive error: Connection reset by peer (104)<br>
Erreur de segmentation<br>
++<br>
<br>
Jack<br>
<br>
<br>
<blockquote cite="mid:4F4BFCFC.10108@rybn.org" type="cite"> I miss
something ?<br>
One comment : it is very strange to see two [gemhead] connected
directly in [pix_openni]. Is there a meaning ?<br>
Thanx for help.<br>
++<br>
<br>
Jack<br>
<br>
<br>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>