Hi all. I'm here again :) The small leak in my app is gone. I'm going on with it, now I grab a frame from a video device and I encode it with Theora... The debugger ( valgrind ) says: ... ==2782== Invalid read of size 1 ==2782== at 0x1B94B0BD: PixelLineSearch (scan.c:1482) ==2782== by 0x1B94B35A: PixelLineSearch (scan.c:1597) ==2782== by 0x1B94B447: LineSearchScorePixel (scan.c:1643) ==2782== by 0x1B94B5A4: LineSearchScoreRow (scan.c:1714) ==2782== by 0x1B94C10B: AnalysePlane (scan.c:2244) ==2782== by 0x1B94C357: YUVAnalyseFrame (scan.c:2326) ==2782== by 0x1B950F96: CompressFrame (encoder_toplevel.c:651) ==2782== by 0x1B95181B: theora_encode_YUVin (encoder_toplevel.c:976) ==2782== by 0x80497F4: main (test3.c:281) ==2782== Address 0x1CEC27A7 is 1 bytes before a block of size 8448 alloc'd ==2782== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==2782== by 0x1B945908: PInitFrameInfo (pp.c:139) ==2782== by 0x1B94979A: ScanYUVInit (scan.c:296) ==2782== by 0x1B95159B: theora_encode_init (encoder_toplevel.c:884) ==2782== by 0x804947F: main (test3.c:220) ( repeated many times ) ... I noticed some things: - if I encode images programmatically generated (like in the last app I posted here in the ML...) my debugger says it's all ok (no errors) - if I grab a simple image ( I put a paper in front of the video camera :) ) the Invalid read's message I reported above is fired little times (sometimes also 0) - if I grab an image ( of the room ) the Invalid read's message I reported above is fired many times ( variable ) So... I suppose the problem is ( like the debugger noticed :) ) related to the frame analysis... I think there's a small bug in it. It seems to read 1 byte before the correct memory address... 8448 bytes... is 352 ( my width ) * 24 ( CHLOCALS_CB_ROWS = INTERNAL_BLOCK_HEIGHT * 3 = 8 * 3 ( in my system ) ) It can be dangerous a wrong read in the application I'm building... As I told, I have little experience with Theora so... help me please if you can :) -Mat-
Mat wrote:> I noticed some things: > - if I encode images programmatically generated (like in the last app > I posted here in the ML...) my debugger says it's all ok (no errors) > - if I grab a simple image ( I put a paper in front of the video > camera :) ) the Invalid read's message I reported above is fired > little times (sometimes also 0) > - if I grab an image ( of the room ) the Invalid read's message I > reported above is fired many times ( variable )[UPDATE] Looking in the debugger output the buffer subject of the Invalid read' is in the file pp.c row 139: ppi->ChLocals _ogg_malloc(ppi->ScanConfig.VideoFrameWidth* sizeof(*ppi->ChLocals) * CHLOCALS_CB_ROWS); If I change this lines in: ppi->ChLocals _ogg_malloc(ppi->ScanConfig.VideoFrameWidth* sizeof(*ppi->ChLocals) * CHLOCALS_CB_ROWS + 2); memset( ppi->ChLocals, 0, ppi->ScanConfig.VideoFrameWidth*sizeof(*ppi->ChLocals) * CHLOCALS_CB_ROWS + 2 ); ppi->ChLocals++; The debugger says it's all ok (there's a small memory leak because of ppi->ChLocals++ , free is trying to free the next byte, ignored for my test of course) So it seems the problem is with this buffer, and not only a reading of 1 byte before the beginning but also a readinf of 1 byte after the ending... I tryed to allocate only 1 more byte for ppi->ChLocals , with and without ppi->ChLocals++ ( to get a boundary byte before and then a boundary byte after ) Hope it could help...
On Fri, Oct 28, 2005 at 02:40:30PM +0200, Mat wrote:> The small leak in my app is gone.Glad we found it.> ==2782== Invalid read of size 1 > ==2782== at 0x1B94B0BD: PixelLineSearch (scan.c:1482)Yes, the scan stuff will definitely be input dependent. Good spotting, this is a real bug (inherited from the VP3 codebase, looks like). There are similar issues with some of the other search directions. Has anyone else read this code? I'm a little unclear on why the bounds check it does do can just wrap the buffer. Obviously the bounds check needs to be fixed/augmented, but I'm not sure what it should in those cases. -r