Hello, i compiled pix_openni for my Ubuntu 11.04 with Gem 0.93 and Pd 0.42.6.
When i open the patch 'pix_openni-help.pd', i get in the Pd console : [pix_openni]: pix_openni 0.03 - experimental - 2011/2012 by Matthias Kronlachner [pix_openni]: using multiple kinects not available now... chosen ID: 0 [pix_openni]: OPEN NI initialised successfully. And [pix_openni] object seems to be OK.
But when i create the Gemwin, Pd crash : Erreur de segmentation jack@jack-N55SF:~$ socket receive error: Connection reset by peer (104)
I did something bad ? ++
Jack
Le 2012-02-24 à 16:03:00, Jack a écrit :
But when i create the Gemwin, Pd crash : Erreur de segmentation I did something bad ?
des plantages comme ça sont injustifiables.
ressaye avec gdb et/ou valgrind.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 24/02/2012 17:18, Mathieu Bouchard a écrit :
Le 2012-02-24 à 16:03:00, Jack a écrit :
But when i create the Gemwin, Pd crash : Erreur de segmentation I did something bad ?
des plantages comme ça sont injustifiables.
ressaye avec gdb et/ou valgrind.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hello Mathieu,
Here the output with valgrind when i create the gemwin :
==4048== Invalid read of size 4 ==4048== at 0x49C6B94: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==4048== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==4048== Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd ==4048== at 0x4025315: calloc (vg_replace_malloc.c:467) ==4048== by 0x80B8710: getbytes (in /usr/bin/pd) ==4048== ==4048== Invalid read of size 1 ==4048== at 0x49C6814: GemBase::gem_startstopMess(int) (GemBase.cpp:102) ==4048== by 0x49C6B9E: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==4048== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==4048== Address 0x11 is not stack'd, malloc'd or (recently) free'd ==4048== ==4048== ==4048== Process terminating with default action of signal 11 (SIGSEGV) ==4048== Access not within mapped region at address 0x11 ==4048== at 0x49C6814: GemBase::gem_startstopMess(int) (GemBase.cpp:102) ==4048== by 0x49C6B9E: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==4048== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==4048== If you believe this happened as a result of a stack ==4048== overflow in your program's main thread (unlikely but ==4048== possible), you can try to increase the size of the ==4048== main thread stack using the --main-stacksize= flag. ==4048== The main thread stack size used in this run was -1. ==4048== ==4048== HEAP SUMMARY: ==4048== in use at exit: 65,622,038 bytes in 45,892 blocks ==4048== total heap usage: 114,083 allocs, 68,191 frees, 143,231,167 bytes allocated ==4048== ==4048== LEAK SUMMARY: ==4048== definitely lost: 17,149 bytes in 61 blocks ==4048== indirectly lost: 10,576 bytes in 607 blocks ==4048== possibly lost: 320,500 bytes in 4,906 blocks ==4048== still reachable: 65,273,813 bytes in 40,318 blocks ==4048== suppressed: 0 bytes in 0 blocks ==4048== Rerun with --leak-check=full to see details of leaked memory ==4048== ==4048== For counts of detected and suppressed errors, rerun with: -v ==4048== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2643 from 11) socket receive error: Connection reset by peer (104) Erreur de segmentation
Thanx. ++
Jack
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
hi!
did you try the examples included in openni and nite? are they working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) if you just create the gemwin without starting rendering is it still crashing?
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 25/02/2012 14:39, Matthias Kronlachner a écrit :
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
hi!
did you try the examples included in openni and nite? are they working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) if you just create the gemwin without starting rendering is it still crashing?
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Matthias,
I don't have a kinect today. I will try later. Creating the gemwin without the rendering doesn't crash Pd. (It was a mistake to said that in my first email). Thanx for your help. ++
Jack
Am 25.02.12 16:08, schrieb Jack:
Le 25/02/2012 14:39, Matthias Kronlachner a écrit :
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
hi!
did you try the examples included in openni and nite? are they working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) if you just create the gemwin without starting rendering is it still crashing?
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Matthias,
I don't have a kinect today. I will try later. Creating the gemwin without the rendering doesn't crash Pd. (It was a mistake to said that in my first email). Thanx for your help.
ah ok, you tried it without kinect?
i just found a bug if there is no kinect available and you want to use handtracking it crashed. but i fixed that. so at least in osx there is no problem now to use pix_openni without a kinect connected. but anyway it doesn't make a lot of sense ;-)
matthias
++
Jack
Le 25/02/2012 17:13, Matthias Kronlachner a écrit :
Am 25.02.12 16:08, schrieb Jack:
Le 25/02/2012 14:39, Matthias Kronlachner a écrit :
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd at 0x4025315: calloc (vg_replace_malloc.c:467) by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
hi!
did you try the examples included in openni and nite? are they working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) if you just create the gemwin without starting rendering is it still crashing?
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Matthias,
I don't have a kinect today. I will try later. Creating the gemwin without the rendering doesn't crash Pd. (It was a mistake to said that in my first email). Thanx for your help.
ah ok, you tried it without kinect?
i just found a bug if there is no kinect available and you want to use handtracking it crashed. but i fixed that. so at least in osx there is no problem now to use pix_openni without a kinect connected. but anyway it doesn't make a lot of sense ;-)
matthias
++
Jack
I tried with and without kinect. I will try tomorrow and i will keep you informed. ++
Jack
Le 26/02/2012 19:13, Jack a écrit :
Le 25/02/2012 17:13, Matthias Kronlachner a écrit :
Am 25.02.12 16:08, schrieb Jack:
Le 25/02/2012 14:39, Matthias Kronlachner a écrit :
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
> Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore an external has to be compiled with the right set of .h files.
There were also at least two more intermediate steps for those who used SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
> Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd > at 0x4025315: calloc (vg_replace_malloc.c:467) > by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at possible mismatching struct{} definitions.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Here the output of valgrind before i create the gemwin, it seems there is no trace of 'invalid write' :
==2417== HEAP SUMMARY: ==2417== in use at exit: 10,269,451 bytes in 14,507 blocks ==2417== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2417== ==2417== LEAK SUMMARY: ==2417== definitely lost: 14,663 bytes in 50 blocks ==2417== indirectly lost: 8,291 bytes in 488 blocks ==2417== possibly lost: 1,525 bytes in 56 blocks ==2417== still reachable: 10,244,972 bytes in 13,913 blocks ==2417== suppressed: 0 bytes in 0 blocks ==2417== Rerun with --leak-check=full to see details of leaked memory ==2417== ==2417== For counts of detected and suppressed errors, rerun with: -v ==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2418== ==2418== HEAP SUMMARY: ==2418== in use at exit: 10,269,451 bytes in 14,507 blocks ==2418== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2418== ==2418== LEAK SUMMARY: ==2418== definitely lost: 14,663 bytes in 50 blocks ==2418== indirectly lost: 8,291 bytes in 488 blocks ==2418== possibly lost: 1,525 bytes in 56 blocks ==2418== still reachable: 10,244,972 bytes in 13,913 blocks ==2418== suppressed: 0 bytes in 0 blocks ==2418== Rerun with --leak-check=full to see details of leaked memory ==2418== ==2418== For counts of detected and suppressed errors, rerun with: -v ==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2419== ==2419== HEAP SUMMARY: ==2419== in use at exit: 10,269,451 bytes in 14,507 blocks ==2419== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2419== ==2419== LEAK SUMMARY: ==2419== definitely lost: 14,663 bytes in 50 blocks ==2419== indirectly lost: 8,291 bytes in 488 blocks ==2419== possibly lost: 1,525 bytes in 56 blocks ==2419== still reachable: 10,244,972 bytes in 13,913 blocks ==2419== suppressed: 0 bytes in 0 blocks ==2419== Rerun with --leak-check=full to see details of leaked memory ==2419== ==2419== For counts of detected and suppressed errors, rerun with: -v ==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2420== ==2420== HEAP SUMMARY: ==2420== in use at exit: 10,269,451 bytes in 14,507 blocks ==2420== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2420== ==2420== LEAK SUMMARY: ==2420== definitely lost: 14,663 bytes in 50 blocks ==2420== indirectly lost: 8,291 bytes in 488 blocks ==2420== possibly lost: 1,525 bytes in 56 blocks ==2420== still reachable: 10,244,972 bytes in 13,913 blocks ==2420== suppressed: 0 bytes in 0 blocks ==2420== Rerun with --leak-check=full to see details of leaked memory ==2420== ==2420== For counts of detected and suppressed errors, rerun with: -v ==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11)
Thanx for your help. ++
Jack
hi!
did you try the examples included in openni and nite? are they working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) if you just create the gemwin without starting rendering is it still crashing?
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Matthias,
I don't have a kinect today. I will try later. Creating the gemwin without the rendering doesn't crash Pd. (It was a mistake to said that in my first email). Thanx for your help.
ah ok, you tried it without kinect?
i just found a bug if there is no kinect available and you want to use handtracking it crashed. but i fixed that. so at least in osx there is no problem now to use pix_openni without a kinect connected. but anyway it doesn't make a lot of sense ;-)
matthias
++
Jack
I tried with and without kinect. I will try tomorrow and i will keep you informed. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have a kinect today. But it still doesn't work. Here is what i do :
- downloaded unstable OpenNi from
http://www.openni.org/Downloads/OpenNIModules.aspx
cd /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/
$ sudo sh install.sh
$ git clone git://github.com/avin2/SensorKinect.git
$ cd /home/jack/SensorKinect/Platform/Linux/CreateRedist/
$ sudo sh install.sh
downloaded unstable NITE from
http://www.openni.org/Downloads/OpenNIModules.aspx
- cd /home/jack/Téléchargements/NITE-Bin-Dev-Linux-x86-v1.5.2.21
- $ sudo sh install.sh
I use Ubuntu 11.04, Pd 0.42.6 and Gem 0.93.git fad1264.
I put the right path to Pd, Gem and OpenNi in the Makefile, then :
$ cd /home/jack/pix_openni $ make
I get a lot of warning in the console but no error :
g++ -fPIC -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -lOpenNI -DGEM_OPENCV_VERSION="" -g -DLINUX -Ilib/pd/src -I. -I/home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include -I/home/jack/Gem/src -Ilib/pd/src `` -o pix_openni.o -c pix_openni.cc In file included from pix_openni.h:32:0, from pix_openni.cc:19: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4337:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4338:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4340:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4358:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4359:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4361:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4659:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4660:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4662:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4680:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4681:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:4683:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5523:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5524:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5526:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5551:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5552:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5554:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5581:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5582:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5584:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5617:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5618:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5620:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5710:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5711:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5713:0: warning: ignoring #pragma warning /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::OutputMetaData::OutputMetaData(const XnUInt8**)’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:253:12: warning: ‘xn::OutputMetaData::m_nAllocatedSize’ will be initialized after /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:247:12: warning: ‘XnUInt8* xn::OutputMetaData::m_pAllocatedData’ /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:132:10: warning: when initialized here /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::DepthMetaData::DepthMetaData()’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:466:39: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::ImageMetaData::ImageMetaData()’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:587:39: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:588:39: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:589:46: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:590:46: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::IRMetaData::IRMetaData()’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:768:33: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::SceneMetaData::SceneMetaData()’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:920:34: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::Query::Query(XnNodeQuery*)’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:1394:10: warning: ‘xn::Query::m_bAllocated’ will be initialized after /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:1393:16: warning: ‘XnNodeQuery* xn::Query::m_pQuery’ /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:1295:10: warning: when initialized here /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::EnumerationErrors::EnumerationErrors()’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5449:10: warning: ‘xn::EnumerationErrors::m_bAllocated’ will be initialized after /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5448:24: warning: ‘XnEnumerationErrors* xn::EnumerationErrors::m_pErrors’ /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5349:10: warning: when initialized here /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h: In constructor ‘xn::EnumerationErrors::EnumerationErrors(XnEnumerationErrors*, XnBool)’: /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5449:10: warning: ‘xn::EnumerationErrors::m_bAllocated’ will be initialized after /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5448:24: warning: ‘XnEnumerationErrors* xn::EnumerationErrors::m_pErrors’ /home/jack/Téléchargements/OpenNI-Bin-Dev-Linux-x86-v1.5.2.23/Include/XnCppWrapper.h:5357:10: warning: when initialized here pix_openni.cc: In member function ‘virtual void pix_openni::render(GemState*)’: pix_openni.cc:664:45: warning: comparison between signed and unsigned integer expressions pix_openni.cc:664:90: warning: comparison between signed and unsigned integer expressions pix_openni.cc: In static member function ‘static void pix_openni::floatRecordMessCallback(void*, t_floatarg)’: pix_openni.cc:1364:53: warning: comparison with string literal results in unspecified behaviour pix_openni.cc: In static member function ‘static void pix_openni::floatPlayMessCallback(void*, t_floatarg)’: pix_openni.cc:1394:53: warning: comparison with string literal results in unspecified behaviour pix_openni.cc: In static member function ‘static void pix_openni::openMessCallback(void*, std::string)’: pix_openni.cc:1440:25: warning: comparison with string literal results in unspecified behaviour gcc -export_dynamic -shared -lOpenNI -o pix_openni.pd_linux pix_openni.o -lOpenNI /usr/bin/ld: warning: cannot find entry symbol xport_dynamic; defaulting to 00000000000047b0 rm pix_openni.o
And the 'pix_openni.pd_linux' is in my 'pix_openni' directory. But when i run the 'pix_openni-help.pd' patch and start rendering, Pd crash. The output with valgrind is : ==2722== HEAP SUMMARY: ==2722== in use at exit: 10,269,451 bytes in 14,507 blocks ==2722== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2722== ==2722== LEAK SUMMARY: ==2722== definitely lost: 14,663 bytes in 50 blocks ==2722== indirectly lost: 8,291 bytes in 488 blocks ==2722== possibly lost: 1,525 bytes in 56 blocks ==2722== still reachable: 10,244,972 bytes in 13,913 blocks ==2722== suppressed: 0 bytes in 0 blocks ==2722== Rerun with --leak-check=full to see details of leaked memory ==2722== ==2722== For counts of detected and suppressed errors, rerun with: -v ==2722== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2723== ==2723== HEAP SUMMARY: ==2723== in use at exit: 10,269,451 bytes in 14,507 blocks ==2723== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2723== ==2723== LEAK SUMMARY: ==2723== definitely lost: 14,663 bytes in 50 blocks ==2723== indirectly lost: 8,291 bytes in 488 blocks ==2723== possibly lost: 1,525 bytes in 56 blocks ==2723== still reachable: 10,244,972 bytes in 13,913 blocks ==2723== suppressed: 0 bytes in 0 blocks ==2723== Rerun with --leak-check=full to see details of leaked memory ==2723== ==2723== For counts of detected and suppressed errors, rerun with: -v ==2723== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2724== ==2724== HEAP SUMMARY: ==2724== in use at exit: 10,269,451 bytes in 14,507 blocks ==2724== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2724== ==2724== LEAK SUMMARY: ==2724== definitely lost: 14,663 bytes in 50 blocks ==2724== indirectly lost: 8,291 bytes in 488 blocks ==2724== possibly lost: 1,525 bytes in 56 blocks ==2724== still reachable: 10,244,972 bytes in 13,913 blocks ==2724== suppressed: 0 bytes in 0 blocks ==2724== Rerun with --leak-check=full to see details of leaked memory ==2724== ==2724== For counts of detected and suppressed errors, rerun with: -v ==2724== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2725== ==2725== HEAP SUMMARY: ==2725== in use at exit: 10,269,451 bytes in 14,507 blocks ==2725== total heap usage: 44,542 allocs, 30,035 frees, 46,723,012 bytes allocated ==2725== ==2725== LEAK SUMMARY: ==2725== definitely lost: 14,663 bytes in 50 blocks ==2725== indirectly lost: 8,291 bytes in 488 blocks ==2725== possibly lost: 1,525 bytes in 56 blocks ==2725== still reachable: 10,244,972 bytes in 13,913 blocks ==2725== suppressed: 0 bytes in 0 blocks ==2725== Rerun with --leak-check=full to see details of leaked memory ==2725== ==2725== For counts of detected and suppressed errors, rerun with: -v ==2725== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482 from 11) ==2704== Invalid read of size 4 ==2704== at 0x49C6B94: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==2704== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==2704== Address 0x74bf508 is 0 bytes after a block of size 32 alloc'd ==2704== at 0x4025315: calloc (vg_replace_malloc.c:467) ==2704== by 0x80B8710: getbytes (in /usr/bin/pd) ==2704== ==2704== Invalid read of size 1 ==2704== at 0x49C6814: GemBase::gem_startstopMess(int) (GemBase.cpp:102) ==2704== by 0x49C6B9E: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==2704== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==2704== Address 0x11 is not stack'd, malloc'd or (recently) free'd ==2704== ==2704== ==2704== Process terminating with default action of signal 11 (SIGSEGV) ==2704== Access not within mapped region at address 0x11 ==2704== at 0x49C6814: GemBase::gem_startstopMess(int) (GemBase.cpp:102) ==2704== by 0x49C6B9E: GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (GemBase.cpp:237) ==2704== by 0x80B5809: pd_typedmess (in /usr/bin/pd) ==2704== If you believe this happened as a result of a stack ==2704== overflow in your program's main thread (unlikely but ==2704== possible), you can try to increase the size of the ==2704== main thread stack using the --main-stacksize= flag. ==2704== The main thread stack size used in this run was -1. ==2704== ==2704== HEAP SUMMARY: ==2704== in use at exit: 66,321,353 bytes in 49,584 blocks ==2704== total heap usage: 119,094 allocs, 69,510 frees, 144,000,165 bytes allocated ==2704== ==2704== LEAK SUMMARY: ==2704== definitely lost: 17,149 bytes in 61 blocks ==2704== indirectly lost: 10,576 bytes in 607 blocks ==2704== possibly lost: 984,388 bytes in 8,372 blocks ==2704== still reachable: 65,309,240 bytes in 40,544 blocks ==2704== suppressed: 0 bytes in 0 blocks ==2704== Rerun with --leak-check=full to see details of leaked memory ==2704== ==2704== For counts of detected and suppressed errors, rerun with: -v ==2704== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2653 from 11) socket receive error: Connection reset by peer (104) Erreur de segmentation
For information, i can't download the last sources of 'pix_openni' today. Hope this indormation will help to solve my problem. Thanx for your help. ++
Jack
-----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
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@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). 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
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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 28.02.12 00:00, schrieb Jack:
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@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). 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
hi!
did you check if the examples included in OpenNI and Nite work? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) they should be somewhere in the Samples/Bin folder. if they don't work, pix_openni won't work.
ok the crash with video_mode and depth_mode msg is fixed now. but it happend only if image or depth was not started. i was a little bit lazy testing everything without working kinect plugged in. if you send a [bang( it now writes an error message to the console if no device is available.
so i think you have a problem with your openni/sensor kinect installation. did you install sensor kinect? this is the driver which allows openni to access the kinect sensor. (https://github.com/avin2/SensorKinect) you also need the unstable release of OpenNI (-> see install instructions from SensorKinect)
the two gemheads have a meaning - of course. pix_openni outputs two separated pixes - one "rgb" image from the camera (left gemhead and outlet) and one depth image in various formats from the depthsensor (right gemhead and outlet). actually it's more implementation side - it could be realized with one gemhead as well. but i did it this way and for me it's logical. you can also make it with one gemhead and a [t a a] if it looks better for you:
[gemhead] [t a a] | | [pix_openni] ....
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 28/02/2012 06:25, Matthias Kronlachner a écrit :
Am 28.02.12 00:00, schrieb Jack:
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@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). 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
hi!
did you check if the examples included in OpenNI and Nite work? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) they should be somewhere in the Samples/Bin folder. if they don't work, pix_openni won't work.
ok the crash with video_mode and depth_mode msg is fixed now. but it happend only if image or depth was not started. i was a little bit lazy testing everything without working kinect plugged in. if you send a [bang( it now writes an error message to the console if no device is available.
so i think you have a problem with your openni/sensor kinect installation. did you install sensor kinect? this is the driver which allows openni to access the kinect sensor. (https://github.com/avin2/SensorKinect) you also need the unstable release of OpenNI (-> see install instructions from SensorKinect)
the two gemheads have a meaning - of course. pix_openni outputs two separated pixes - one "rgb" image from the camera (left gemhead and outlet) and one depth image in various formats from the depthsensor (right gemhead and outlet). actually it's more implementation side - it could be realized with one gemhead as well. but i did it this way and for me it's logical. you can also make it with one gemhead and a [t a a] if it looks better for you:
[gemhead] [t a a] | | [pix_openni] ....
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
OK, it is working now.
In the pix_openni/README, i would prefer to follow these instructions in 5 steps (in the middle of the page) : http://groups.google.com/group/openni-dev/browse_thread/thread/49a4dd13c045c... instead of :
- get and install OpenNI, NITE and the hacked Primesense Kinect driver --> instruction: https://github.com/avin2/SensorKinect http://www.openni.org/Downloads/OpenNIModules.aspx
And all should be OK.
Matthias, the hand tracking should work fine ? Thanx for this external. ++
Jack
Am 28.02.12 15:47, schrieb Jack:
Le 28/02/2012 06:25, Matthias Kronlachner a écrit :
Am 28.02.12 00:00, schrieb Jack:
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@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). 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
hi!
did you check if the examples included in OpenNI and Nite work? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) they should be somewhere in the Samples/Bin folder. if they don't work, pix_openni won't work.
ok the crash with video_mode and depth_mode msg is fixed now. but it happend only if image or depth was not started. i was a little bit lazy testing everything without working kinect plugged in. if you send a [bang( it now writes an error message to the console if no device is available.
so i think you have a problem with your openni/sensor kinect installation. did you install sensor kinect? this is the driver which allows openni to access the kinect sensor. (https://github.com/avin2/SensorKinect) you also need the unstable release of OpenNI (-> see install instructions from SensorKinect)
the two gemheads have a meaning - of course. pix_openni outputs two separated pixes - one "rgb" image from the camera (left gemhead and outlet) and one depth image in various formats from the depthsensor (right gemhead and outlet). actually it's more implementation side - it could be realized with one gemhead as well. but i did it this way and for me it's logical. you can also make it with one gemhead and a [t a a] if it looks better for you:
[gemhead] [t a a] | | [pix_openni] ....
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
OK, it is working now.
In the pix_openni/README, i would prefer to follow these instructions in 5 steps (in the middle of the page) : http://groups.google.com/group/openni-dev/browse_thread/thread/49a4dd13c045c... instead of :
- get and install OpenNI, NITE and the hacked Primesense Kinect driver --> instruction: https://github.com/avin2/SensorKinect
http://www.openni.org/Downloads/OpenNIModules.aspx
And all should be OK.
Matthias, the hand tracking should work fine ? Thanx for this external. ++
Jack
ok, i will check that. thanks. i think things change every month about installing openni/nite/sensorkinect. but as you found out there are enough resources that help you with the installation out there. thats why i prefer pix_freenect for projects that don't need skeleton tracking. it's a lot more easy to install and i think also cheaper in computation power. the output format of these two objects is basically compatible. so you can always exchange them if you don't need external tracking stuff. just a few initialization messages depending on which output mode you want to have can be different.
for hand tracking you have to make a waving gesture. wave your hand several times after you activated it. after some time nite should recognize your hand and start tracking. if you want more easy hand tracking there is the possibility to use pix_multiblob in combination with filtering the depth image.
if you want to track severall hands you can check the Nite.ini files located in these folders: /usr/etc/primesense/Hands_1_* and uncomment the lines there (remove the ; )
thanks for your reporting. that helps to make it more stable.
matthias
Le 28/02/2012 15:57, Matthias Kronlachner a écrit :
Am 28.02.12 15:47, schrieb Jack:
Le 28/02/2012 06:25, Matthias Kronlachner a écrit :
Am 28.02.12 00:00, schrieb Jack:
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@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). 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
hi!
did you check if the examples included in OpenNI and Nite work? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) they should be somewhere in the Samples/Bin folder. if they don't work, pix_openni won't work.
ok the crash with video_mode and depth_mode msg is fixed now. but it happend only if image or depth was not started. i was a little bit lazy testing everything without working kinect plugged in. if you send a [bang( it now writes an error message to the console if no device is available.
so i think you have a problem with your openni/sensor kinect installation. did you install sensor kinect? this is the driver which allows openni to access the kinect sensor. (https://github.com/avin2/SensorKinect) you also need the unstable release of OpenNI (-> see install instructions from SensorKinect)
the two gemheads have a meaning - of course. pix_openni outputs two separated pixes - one "rgb" image from the camera (left gemhead and outlet) and one depth image in various formats from the depthsensor (right gemhead and outlet). actually it's more implementation side - it could be realized with one gemhead as well. but i did it this way and for me it's logical. you can also make it with one gemhead and a [t a a] if it looks better for you:
[gemhead] [t a a] | | [pix_openni] ....
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
OK, it is working now.
In the pix_openni/README, i would prefer to follow these instructions in 5 steps (in the middle of the page) : http://groups.google.com/group/openni-dev/browse_thread/thread/49a4dd13c045c... instead of :
- get and install OpenNI, NITE and the hacked Primesense Kinect driver --> instruction: https://github.com/avin2/SensorKinect
http://www.openni.org/Downloads/OpenNIModules.aspx
And all should be OK.
Matthias, the hand tracking should work fine ? Thanx for this external. ++
Jack
ok, i will check that. thanks. i think things change every month about installing openni/nite/sensorkinect. but as you found out there are enough resources that help you with the installation out there. thats why i prefer pix_freenect for projects that don't need skeleton tracking. it's a lot more easy to install and i think also cheaper in computation power. the output format of these two objects is basically compatible. so you can always exchange them if you don't need external tracking stuff. just a few initialization messages depending on which output mode you want to have can be different.
OK, good to know.
for hand tracking you have to make a waving gesture. wave your hand several times after you activated it. after some time nite should recognize your hand and start tracking. if you want more easy hand tracking there is the possibility to use pix_multiblob in combination with filtering the depth image.
OK, I will try it in the minute.
if you want to track severall hands you can check the Nite.ini files located in these folders: /usr/etc/primesense/Hands_1_* and uncomment the lines there (remove the ; )
Yep.
thanks for your reporting. that helps to make it more stable.
Thanx for your work. ++
Jack
matthias
Le 28/02/2012 16:40, Jack a écrit :
Le 28/02/2012 15:57, Matthias Kronlachner a écrit :
Am 28.02.12 15:47, schrieb Jack:
Le 28/02/2012 06:25, Matthias Kronlachner a écrit :
Am 28.02.12 00:00, schrieb Jack:
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@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). 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
hi!
did you check if the examples included in OpenNI and Nite work? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis) they should be somewhere in the Samples/Bin folder. if they don't work, pix_openni won't work.
ok the crash with video_mode and depth_mode msg is fixed now. but it happend only if image or depth was not started. i was a little bit lazy testing everything without working kinect plugged in. if you send a [bang( it now writes an error message to the console if no device is available.
so i think you have a problem with your openni/sensor kinect installation. did you install sensor kinect? this is the driver which allows openni to access the kinect sensor. (https://github.com/avin2/SensorKinect) you also need the unstable release of OpenNI (-> see install instructions from SensorKinect)
the two gemheads have a meaning - of course. pix_openni outputs two separated pixes - one "rgb" image from the camera (left gemhead and outlet) and one depth image in various formats from the depthsensor (right gemhead and outlet). actually it's more implementation side - it could be realized with one gemhead as well. but i did it this way and for me it's logical. you can also make it with one gemhead and a [t a a] if it looks better for you:
[gemhead] [t a a] | | [pix_openni] ....
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
OK, it is working now.
In the pix_openni/README, i would prefer to follow these instructions in 5 steps (in the middle of the page) : http://groups.google.com/group/openni-dev/browse_thread/thread/49a4dd13c045c... instead of :
- get and install OpenNI, NITE and the hacked Primesense Kinect
driver --> instruction: https://github.com/avin2/SensorKinect http://www.openni.org/Downloads/OpenNIModules.aspx
And all should be OK.
Matthias, the hand tracking should work fine ? Thanx for this external. ++
Jack
ok, i will check that. thanks. i think things change every month about installing openni/nite/sensorkinect. but as you found out there are enough resources that help you with the installation out there. thats why i prefer pix_freenect for projects that don't need skeleton tracking. it's a lot more easy to install and i think also cheaper in computation power. the output format of these two objects is basically compatible. so you can always exchange them if you don't need external tracking stuff. just a few initialization messages depending on which output mode you want to have can be different.
OK, good to know.
for hand tracking you have to make a waving gesture. wave your hand several times after you activated it. after some time nite should recognize your hand and start tracking. if you want more easy hand tracking there is the possibility to use pix_multiblob in combination with filtering the depth image.
OK, I will try it in the minute.
Very nice, it's perfect ! ;) ++
Jack
if you want to track severall hands you can check the Nite.ini files located in these folders: /usr/etc/primesense/Hands_1_* and uncomment the lines there (remove the ; )
Yep.
thanks for your reporting. that helps to make it more stable.
Thanx for your work. ++
Jack
matthias
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmoelnig -
Jack -
Mathieu Bouchard -
Matthias Kronlachner