trace-malloc bloat test crashes on nye tbox during shutdown

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
12 years ago
12 years ago

People

(Reporter: ajschult784, Assigned: graydon)

Tracking

({crash, regression})

Trunk
x86
Linux
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
Posted file stacktrace
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

12 years ago
Flags: blocking1.9?

Updated

12 years ago
Assignee: nobody → graydon
Flags: blocking1.9? → blocking1.9+
(Reporter)

Comment 1

12 years ago
Posted file stack from valgrind
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

12 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

12 years ago
I'm not seeing this crash in the tinderboxes anymore. Is it still happening?
(Reporter)

Comment 5

12 years ago
Posted file valgrind log
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

12 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

12 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
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.