Closed
Bug 366241
Opened 18 years ago
Closed 17 years ago
trace-malloc bloat test crashes on nye tbox during shutdown
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ajschult784, Assigned: graydon)
References
()
Details
(Keywords: crash, regression)
Attachments
(3 files)
With the landing of the cycle collector, nye crashes during shutdown of the trace-malloc bloat test. I don't see the crash on my desktop's builds, but if I run the test on nye interactively, I still hit it. In fact, I hit the crash if I set the DISPLAY to something invalid so that it immediately exits.
Reporter | ||
Updated•18 years ago
|
Blocks: cycle-collector
Updated•18 years ago
|
Flags: blocking1.9?
Updated•18 years ago
|
Assignee: nobody → graydon
Flags: blocking1.9? → blocking1.9+
Reporter | ||
Comment 1•17 years ago
|
||
I trimmed nsAppRunner's main method down to argc = NS_TraceMallocStartupArgs(argc, argv); gtk_init(&argc, &argv); return 0; and it still crashes. I'm attaching a valgrind stack I hit when running with arguments "-P clean --trace-malloc /tmp/malloc.log --shutdown-leaks /tmp/sdleak.log" (-P clean has no real effect, but it makes valgrind see an invalid read instead of a uninitialized conditional jump)
Reporter | ||
Comment 2•17 years ago
|
||
I mentioned in comment 0 that I don't crash running with trace-malloc on my desktop. But running under valgrind, it sees the same errors that valgrind sees on nye.
nsGetTypeName is pretty fishy; it could probably be improved. I don't think this is graydon's fault; he just made us leak something a little more interesting.
Assignee | ||
Comment 4•17 years ago
|
||
I'm not seeing this crash in the tinderboxes anymore. Is it still happening?
Reporter | ||
Comment 5•17 years ago
|
||
I don't see a crash running locally or on the tinderbox, but valgrind still sees the same thing as in attachment 254618 [details]. The line numbers in nsTraceMalloc.c have changed, but it's referencing the same block of code as before.
Assignee | ||
Comment 6•17 years ago
|
||
Two questions: First, is this still really blocking 1.9? It seems minor if it's not actually crashing anything: trace-malloc is not even turned on most of the time. Second, dbaron, can you imagine what's going on in this? It looks to me like trace-malloc hasn't been told that a particular chunk of memory got recycled, and it's enumerating it as the wrong type of pointer during shutdown. Could the cycle collector be interfering with trace-malloc hooking or something?
Could the cycle collector somehow be interfering with trace-malloc hooking only partly? If it interfered completely, trace-malloc pretty much wouldn't do anything. trace-malloc knows what's going on by overriding malloc, free, etc.
Assignee | ||
Comment 8•17 years ago
|
||
As far as I know you have to have DEBUG_CC defined during build and define XPCOM_CC_HOOK_MALLOC at runtime to get malloc hooking.
This looks like it's ok now on http://tinderbox.mozilla.org/SeaMonkey/ . Marking worksforme; not sure when it was fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•