Re: [Valgrind-developers] getting V work with custom allocators?

[Jeroen N. W. <jn...@xs...>]

> On Sat, 2005-12-17 at 10:11 +0100, Jeroen N. Witmond wrote:
>> > On Tue, 2005-12-06 at 18:37 +0000, Ashley Pittman wrote:
>> >> I'm still seeing both crashes within valgrind and no error reports
>> where
>> >> there should be some but I'm no further forward finding the cause of
>> >> this yet.  A typical stack trace looks like this with what appears to
>> be
>> >> two assertion failures in mac_leakcheck.c, the first one at line 588
>> >> "tl_assert(p_min != NULL)" and a second one at 539.
>> >
>> > I gave up trying to work with my library and went back to basics
>> coding
>> > up a reproducer from scratch, can somebody take a look at this for me
>> > please.
>> >
>> > With the patch I posted yesterday it crashes with this error:
>> >
>> > Memcheck: mac_leakcheck.c:539 (full_report): Assertion
>> > 'lc_markstack[i].state == IndirectLeak' failed.
>> [snip stacktrace]
>>
>> I've hacked together a patch (for trunk, needing work for COMPVBITS) to
>> produce leak checks for custom allocated blocks and mempools, as well as
>> for malloc'd blocks. I basically did this by separating the bookkeeping
>> for custom blocks from that for malloc'd blocks, and invoking the leak
>> detector for each type (malloc, custom or mempool). The problem with
>> this
>> patch is that I cannot get it to work without disabling this
>> 'tl_assert(lc_markstack[i].state == IndirectLeak' in 'static void
>> full_report(ThreadId tid)'. For custom blocks, the state I get is
>> Unreached, 'definitely lost'.
>
> I'd be interested in seeing that patch.  Is your patch so that leaks are
> reported differently for custom and heap blocks?

Yes. Read here:
http://www.xs4all.nl/~jnw/valgrind/custom-alloc/custom-alloc.html
for more details and the link to download the patch.

Happy New Year!

Jeroen.

>
>> Can anybody tell me if the tl_assert() is too critical, or if this is
>> some
>> other bug? Thanks.
>
> Well it's been removed now so it's not *too* critical.  I found that
> when I removed it I got different error totals depending on if I set the
> --leak-check=full option or not :(  I don't really understand why this
> is but hope to get time to at least look into in the new year.
>
> Ashley,
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>