Thusfar the helgrind reports have gone away each of the times I ran this
application without dlmalloc. It IS a race condition and while I was able
to run it 3-4 times without report that's only 1-2 more times than the
cases where I get one report in 1-2 run. The time it takes to do the
minimal test is about 40 minutes, the helgrind report can appear (with the
exact same test data - but the data is being fed via sockets from a
capture file) after 3-4 mins or 35 mins so I am never sure until I do
extensive trials if the problem "goes away" - I just know when it exists.
The thing is though, the line in SendHandler referenced actually led me to
find an actual race condition where a thread can delete a memory area,
another get it in allocation then another deallocate the memory that was
just deleted in the first thread then given to a different thread for a
different object (really really bad design led to this sneaking through -
but it is now fixed. The window was quite small, 2 other threads had to do
the "right" wrong thing during the window of execution between:
delete tcpClient;
tcpClient = 0;
I know this never happened in production (or rather not as common as the
problem we see) because this only occurs when we cannot connect upstream.
However, I fixed it, of course.
So, the fact that it was near a real issue had me thinking that was the
issue but it did not go away once I fixed the code. In the past when I
compiled against dlmalloc (the app that uses it is from another division)
I had too many reports to see the real errors and removed dlmalloc. This
time, only this one report. Which made me think helgrind (or dlmalloc)
changed to work with each other and makes me want to see what it meant.
It's the opposite of crying wolf this time - it is the only dlmalloc
complaint.
Of course... it could be a false positive and helgrind is just not seeing
(or drd) the issue that is the real problem at all (obviously not
unlikely.)
---Dan
On Thu, Apr 30, 2009 at 10:28 AM, Bart Van Assche
<[email protected]> wrote:
> On Wed, Apr 29, 2009 at 7:56 PM, <[email protected]>
wrote:
>> This is my first post. I am using Valgrind 3.4.1. The application I
was
>> testing for what seems to be memory corruption is compiled along with
>> dlmalloc-2.8.3.c
>
> Have you considered to relink your application such that it uses
> glibc's memory allocator instead of dlmalloc before analyzing it with
> Helgrind or DRD ?
That may or may not work depending on a particular use of a custom
malloc library.
In our case (we use tcmalloc) we cannot replace the custom malloc with
the glibc's malloc because many our applications rely on the fact that
we use tcmalloc.
--kcc
>
> Bart.
>
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
