[PD] fux_kinect

[Mathieu Bouchard]

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

> Attached is the output of "valgrind --leak-check=full pdextended" and 
> opening fux_kinect-help.pd.

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.

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC