Le 2011-11-11 à 19:52:00, tim vets a écrit :
the 'where' output remains the same afaict...
Well, you're lucky, because it crashes really quickly after the bug :
#7 0xb42514da in freenect_init () from /usr/local/lib/libfreenect.so.0.0
#8 0xb43824cf in fux_kinect::fux_kinect (this=0x8612638, argc=0,
argv=0xbfffec4c) at fux_kinect.cpp:84
This (and the Valgrind report that you didn't post) all point to the first
half of the fux_kinect constructor. I just tried reading it for the first
time. It contains the line :
gl_frame_cond = (pthread_cond_t*) malloc(sizeof(pthread_mutex_t));
but the size of a pthread mutex is either 24 bytes or 40 bytes (32-bit vs
64-bit), and the size of a pthread cond is 48 bytes (though some bytes
might be unused in 32-bit mode). This causes memory corruption in the next
line already :
pthread_cond_init(gl_frame_cond, NULL);
So the fix is to use pthread_cond_t in the malloc call above.
But a better fix might be to not use malloc at all for those things,
unless there's a good reason to use it. Less opportunities for bugs.
______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
