126915 - trace-malloc broken in win32 gmake builds

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P4)

Description

[hacker formerly known as [e-mail]]

Comment 1

[hacker formerly known as [e-mail]]

Attachment: Add win32 ifdefs for trace-malloc to xpcom/base/Makefile.in

Forgot this hunk when I checked in the other trace-malloc changes. :-/

Comment 2

[Brian Ryner (not reading)]

Comment on attachment 70677 [details] [diff] [review]
Add win32 ifdefs for trace-malloc to xpcom/base/Makefile.in

r=bryner

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

r=dbaron on the patch changing MOZ_TRACE_MALLOC to NS_TRACE_MALLOC in
xpcom/build/Makefile.in that we discussed yesterday.

Comment 4

[hacker formerly known as [e-mail]]

Attachment: win32 trace-malloc v1.1

This patch:
* Changes MOZ_TRACE_MALLOC ifdefs to NS_TRACE_MALLOC ifdefs
* Links against the trace-malloc utils against libxpcom instead of just xpcomds

* Builds NSPR in debug mode on win32 if trace-malloc is enabled
* Adds a few "defined()" checks to diffbloatdump.pl so that it will work for
perl 5.6.1
* Adds a couple of checks for \r so that it works on win32.

Comment 5

[hacker formerly known as [e-mail]]

I'm still seeing problems even with this patch.  The first run works fine but at
the end of the second (sometimes third) trace-malloc bloat test, mozilla crashes
with the message:

The instruction at "0x10065fe9" referenced memory at "0x01d3b2e8".  The memory
could not be "read".

MSVC's debugger is unable to attach itself to the crashed process.

Garrett, dbaron said that you were working on trace-malloc with the nmake build.
 Have you seen anything like this before?

Comment 6

[Asa Dotzler [:asa]]

a=asa (on behalf of drivers) for checkin to 0.9.9

Comment 7

[Garrett Arch Blythe]

I haven't seen the nmake trace malloc enabled builds crash per se, though I have
not run against the bloat tests several times in specific.

I am biased that your makefile changes are likely correct, and that we have a
more general problem at hand.  What is the bloat test anyhow: "bloaturls.txt"? 
I can try to give it a go a few times to see if I see a crash.

Comment 8

[hacker formerly known as [e-mail]]

You'll have to build with debugging enabled or non-debug with logrefcnt turned
on in order for bloat tests to run properly.  You'll have to manually add
-DFORCE_BUILD_REFCNT_LOGGING=1 to CFLAGS to turn on logrefcnt. (I didn't realize
that we don't have a nmake option for it.)

Then: 

mozilla -f bloaturls.txt --trace-malloc tm.log --shutdown-leaks sd.log

Comment 9

[hacker formerly known as [e-mail]]

Patch has been checked in.

Comment 10

[hacker formerly known as [e-mail]]

So, it looks like it's just --shutdown-leaks that's broken.  If I remove that
option, the tinderbox cycles fine.  

Comment 11

[hacker formerly known as [e-mail]]

The --shutdown-leaks problem appears to be fixed now.  I can't test the exact
failure I was seeing before because the page cycler isn't being invoked when |-f
bloaturls.txt| is being used so no pages are loaded (bug 155224) and the
tinderbox just times out.