From: Julian S. <js...@ac...> - 2003-05-05 23:04:10
|
Version 1.9.6 (7 May 2003 or thereabouts) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Major changes in 1.9.6: - Improved threading support for glibc >= 2.3.2 (SuSE 8.2, RedHat 9, to name but two ...) It turned out that 1.9.5 had problems with threading support on glibc >= 2.3.2, usually manifested by threaded programs deadlocking in system calls, or running unbelievably slowly. Hopefully these are fixed now. 1.9.6 is the first valgrind which gives reasonable support for glibc-2.3.2. Also fixed a 2.3.2 problem with pthread_atfork(). - Majorly expanded FAQ.txt. We've added workarounds for all common problems for which a workaround is known. Minor changes in 1.9.6: - Fix identification of the main thread's stack. Incorrect identification of it was causing some on-stack addresses to not get identified as such. This only affected the usefulness of some error messages; the correctness of the checks made is unchanged. - Support for kernels >= 2.5.68. - Dummy implementations of __libc_current_sigrtmin, __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully good enough to keep alive programs which previously died for lack of them. - Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request. - Fix bug in the DWARF2 debug line info loader, when instructions following each other have source lines far from each other (e.g. with inlined functions). - Debug info reading: read symbols from both "symtab" and "dynsym" sections, rather than merely from the one that comes last in the file. - New syscall support: prctl(), creat(), lookup_dcookie(). - When checking calls to accept(), recvfrom(), getsocketopt(), don't complain if buffer values are NULL. - Try and avoid assertion failures in mash_LD_PRELOAD_and_LD_LIBRARY_PATH. - Minor bug fixes in cg_annotate. |
From: Alex I. <ale...@in...> - 2003-05-29 21:57:06
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I hope someone could give me a hand here - Valgrind is reporting mismatched free/delete operation in one of my classes, however I am doing plain new and matching delete. Here is a snippet of the log: <p>==15083== Thread 24: <br>==15083== Mismatched free() / delete / delete [] <br>==15083== at 0x4015E62D: __builtin_delete (vg_clientfuncs.c:199) <br>==15083== by 0x4029059B: BTNode::~BTNode(void) (../src/BinTree.cpp:71) <br>==15083== by 0x459D3F69: SymTableEntry::~SymTableEntry(void) (../src/SymTable.cc:168) <br>... <br>==15083== Address 0x4480F42C is 0 bytes inside a block of size 120 alloc'd <br>==15083== at 0x4015E310: malloc (vg_clientfuncs.c:103) <br>==15083== by 0x459D9CAB: __builtin_new (../../gcc-2.95.3/gcc/cp/new1.cc:77) <br>==15083== by 0x459D3D8B: SymTable::Insert(char const *, int, int, int) (../src/SymTable.cc:96) <p>Now, as you can see the allocation is done by __builtin_new, and deallocation by __builtin_delete - no mismatch here. What is strange though is that __builtin_delete is intercepted by valgrind, whereas __builtin_new goes into compiler and valgrind sees only malloc from there. Quite naturally, it reports a mismatch in this case. Does anyone know a reason why this is happening and how to fix it ? <p>Thanks! <br>Alex <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
From: Jeremy F. <je...@go...> - 2003-05-29 23:54:24
|
On Thu, 2003-05-29 at 14:56, Alex Ivershen wrote: > Now, as you can see the allocation is done by __builtin_new, and > deallocation by __builtin_delete - no mismatch here. What is strange > though is that __builtin_delete is intercepted by valgrind, whereas > __builtin_new goes into compiler and valgrind sees only malloc from > there. Quite naturally, it reports a mismatch in this case. Does > anyone know a reason why this is happening and how to fix it ? The problem is that Valgrind isn't intercepting __builtin_new, so its using the compiler's version of it, which ends up calling malloc(); therefore, Valgrind sees the block as being allocated with malloc(). It does successfully intercept __builtin_delete, so that's why it sees the mismatch. What compiler version are you using? Are you linking with g++ (rather than just plain gcc)? J |