Bug 201936

Summary:	heap corruption crashes on mac, possibly during leak detection?
Product:	[Developer tools] valgrind	Reporter:	Dan Kegel <dank>
Component:	general	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	crash	CC:	njn
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	wanted3.6.0
Platform:	Compiled Sources
OS:	Other
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Dan Kegel 2009-07-29 22:51:29 UTC

Version:            (using Devel)
OS:                OS X
Installed from:    Compiled sources

Under mac valgrind, chromium ui tests crash horribly.
Here's a log (done with --log-file=valgrind.tmp/memcheck.%p);
it shows three or four different kinds of horrible crashes
in different processes, all possibly related.  The
app itself seems to finish fine.

http://build.chromium.org/buildbot/waterfall.fyi/builders/Mac%20UI%201%20of%203%20(valgrind)/builds/387/steps/valgrind%20test:%20ui/logs/stdio

-- begin ---
</error>
findSb: can't find pointer 0xDAC8340 in arena 'client'
</valgrindoutput>
valgrind: the 'impossible' happened:
     findSb: VG_(arena_free)() in wrong arena?
-- end --

or

-- begin --
valgrind: m_mallocfree.c:1505 (vgPlain_arena_free): Assertion 'other_b-1 == (Block*)sb_end' failed.
-- end --

or

-- begin --
VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
-- end --

Some of the log files simply end before any leak information
is shown; perhaps that's a fourth kind of horrible crash.
(Already filed that one as bug 201923, as that one also happens by
itself, and on Linux as well as mac.)

Comment 1 Nicholas Nethercote 2009-07-30 00:17:52 UTC

(In reply to comment #0)
>
> -- begin ---
> </error>
> findSb: can't find pointer 0xDAC8340 in arena 'client'
> </valgrindoutput>
> valgrind: the 'impossible' happened:
>      findSb: VG_(arena_free)() in wrong arena?
> -- end --
> 
> or
> 
> -- begin --
> valgrind: m_mallocfree.c:1505 (vgPlain_arena_free): Assertion 'other_b-1 ==
> (Block*)sb_end' failed.
> -- end --

These ones look like the heap has been corrupted, and usually that's caused by the client program.  Have you fixed all the reported errors prior to this point?

Comment 2 Dan Kegel 2009-07-30 00:23:15 UTC

I'll check.

Comment 3 Dan Kegel 2009-07-31 22:22:40 UTC

The application is in general fairly clean; it's continuously 
run through its entire test suite under purify on windows 
and valgrind on linux and mac, and we clean up errors fairly promptly.
There is a single invalid write error, but it does not occur in any 
of the runs that crashed.  I'll check again once that has been fixed.

Interesting tidbit: I ran our test suite under valgrind continuously
for a few days, with each test case in a separate run, and
looked at the VALGRIND INTERNAL ERROR reports.  I noticed that
every one went on to say
 valgrind: the 'impossible' happened: Killed by fatal signal
 <stack>
 <frame>
   <ip>0xF0130AAC</ip>
 </frame>
Not sure what that stack is from, though.

Comment 4 Julian Seward 2009-08-04 17:55:01 UTC

See patch containing possible fix in bug 192634 comment #20.
Feedback is solicited as I can't reproduce the problem myself,
hence can't test the patch.