Le 2011-11-14 à 14:44:00, tim vets a écrit :

I think that you better not add --leak-check when just looking for a crash. But the only problem it does, is make the log file bigger.

Here's what I found (summarising the important error messages) :

Invalid write of size 1 at convert_bayer_to_rgb (in libfreenect) by [...] by libusb_handle_events_timeout (in libusb). Address 0xa066360 is [between 0 and 5] bytes after a block of size 307,200 alloc'd

This means that when libusb gives libfreenect the RGGB buffer and libfreenect is converting it to plain RGB, it makes a mistake and writes 6 bytes more than just 640*480 pixels, as if there were 2 extra pixels at the end. But I think that this is a bit misleading. It looks as if Valgrind was skipping a lot of other errors (probably by not able to detect them). Read on.

Then there is invalid write of size 1 from the same place but « Address is 749 bytes inside a block of size 12,800 free'd ». This doesn't look like any malloc that we know about. The number of bytes does not ring a bell either. But then it says that the memory was freed by request of /usr/lib/nvidia-current/libGL.so.270.41.06, which is a part of your video driver. (???)

But I just looked at how convert_bayer_to_rgb is written, and it doesn't look like it writes to more than one buffer. This function only writes 480 rows of 640 columns. But note that it writes RGB values, three bytes per pixel. That means you need a malloc(640*480*3) for each of the three RGB buffers in fux_kinect.