|
From: Julian S. <js...@ac...> - 2006-08-26 07:59:19
|
> So the next question is, why doe the malloc/free intercepting > cost ~940MB for konq? It appears drd_malloc_wrappers.c was freeing shadow chunks but not the payload data itself. The attached drd_diffs2.txt, which is again relative to valgrind-5999-drd-2006-08-14.tar.bz2, fixes this problem. I also did a bit of inlining and loop unrolling in drd_bitmap3.c so as to make bm_access_4 faster. I think that fixes the resource problems. konq now starts and exits, even with malloc/free intercepting, in 160M, which is much more reasonable. So I guess we can move on to the questions: - is it robust? - does it find real bugs? I tested it on the following: none/tests/pth_mutexspeed.c none/tests/pth_rwlock.c none/tests/pth_once.c none/tests/pth_cvsimple.c with results: pth_mutexspeed.c - runs ok, no races reported pth_rwlock.c - runs ok, no races reported pth_once.c - runs ok, but many races reported pth_cvsimple.c - drd_mutex.c:95 (mutex_lock): the 'impossible' happened. Bart, can you look at pth_once and pth_cvsimple? It may be that glibc contains some races - I believe we found with Helgrind that there is a statistics counter to do with dynamic linking, which is not protected by a mutex, and the glibc maintainers had no interest in fixing it. However, I still don't understand what it is telling me for pth_once. J |