Having cracked the quality and image size problems that I was having within my frame extractor program, I did something incredibly stupid. I SVN'd the latest version of the libraries and built them. I was then asked to check something on the main program for the project, which does text recognition on overlaid timecodes on the video and on rebuilding that program to a debug version, it suddenly stopped working. It fell over with access violations and av_malloc returning nulls and so on. This did not happen with my earlier library build of a few months ago (sorry, I didn't document the versions as I was more concerened with trying to get it to run at all under Windows).
This is a Windows-based project, written in C and x86 assembler, using statically linked libraries that were built using mingw/msys, on a 32-bit platform. The make was configured with: --enable-memalign-hack -enable-static -disable-shared -extra-cflags="-fno-common" exactly as for the earlier build. In fact, the build steps were: ./configure -enable-memalign-hack -enable-static -disable-shared -extra-cflags="-fno-common" make make install I notice that av_malloc is calling the malloc function in the Windows C-runtime library. I'm using Visual Studio 6 (the last one before the .NET bloat), so I was able to step through the operation of malloc and could see that it was generating a "first chance exception" showing an access violation somewhere around av_free. The program recovers enough to carry on a bit, so I changed the debugger strategy to always top on an access violation. It occurred a second time, deep in the bowels of NTDLL, but the stack trace shows that we originated in av_malloc, requesting 122912 bytes. Now although this lot is going through the debug heap allocation and free stuff, I get similar errors (but more difficult to follow) in a non-debug build of the program, I had naively thought that av_malloc and av_free were wrappers around malloc and free in the gcc library as I built the libraries under msys. Now, have I done something very dumb? Perhaps missed something when I built the new versions of the libraries, or has something changed in av_malloc/av_free. Clive _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
