|
From: Stephane H. <sho...@ni...> - 2007-06-13 16:23:02
|
On Wednesday 13 June 2007 04:08, Christoph Bartoschek wrote: > Am Mittwoch, 13. Juni 2007 schrieb Stephane Hockenhull: > > I dont know if this is a known issue, a problem with our code, or an (up > > to now) unknown bug in valgrind. > > > > on a few projects we're working on that are using both threads and > > fibers, valgrind starts to spew tons of error of invalid access in the > > middle of allocated objects that has definitely not been freed, such as: > > > > ==22128== 6 errors in context 51 of 185: > > ==22128== Thread 1: > > ==22128== Invalid read of size 4 > > ==22128== at 0x4047C80: pthread_cond_signal@@GLIBC_2.3.2 > > (in /lib/libpthread-2.4.so) > > ==22128== by 0x8053D74: DriverProcess(LDI_PATCHER*, unsigned, > > unsigned) (patcher.cpp:820) > > ==22128== by 0x804C4EC: Main_Loop() (main_loop.cpp:59) > > ==22128== by 0x804C967: main (base_kernel.cpp:154) > > ==22128== Address 0x6F68D08 is 736 bytes inside a block of size 788 > > alloc'd ==22128== at 0x402192C: operator new[](unsigned) > > (vg_replace_malloc.c:195) > > Valgrind does not complain that the objects are already freed. Are you sure > that all objects are correctly initialized? For example the mutex and the > condition variable used here? in that case it should say use of uninitialized value, not invalid access. also: ==19109== Invalid write of size 4 ==19109== at 0x4415D74: swapcontext (in /lib/libc-2.4.so) ==19109== Address 0x7F921C8 is 112 bytes inside a block of size 428 alloc'd ==19109== at 0x402192C: operator new[](unsigned) (vg_replace_malloc.c:195) if this was really an error it should crash hard in either case (doing a swap context on random data (ie all cpu registers including the instruction pointer and the stack pointer become junk) and have it succeed is like winning the lottery... I'm still not a millionaire ;) but when I run without valgrind the application churns away happily, and even with valgrind, it complains but still run fine. and as I said the data is not freed (there is no delete on that object in the code as it is part of the application itself, and valgrind seem to confirm it isn't) maybe the problem isnt swapcontext related but something else, in any case, seems like we're doing something that makes valgrind go paranoid. we believe there's a bug in our code that totally messes up valgrind. also, we're not using client requests (memcheck.h) in our code. we're actively investigating it, if some valgrind developers could give us some theories on what could cause this it would help greatly. > Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Stephane Hockenhull SSC-Studios.com |