366241 - trace-malloc bloat test crashes on nye tbox during shutdown

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Andrew Schultz]

Attachment: 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.

Comment 1

[Andrew Schultz]

Attachment: 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)

Comment 2

[Andrew Schultz]

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.

Comment 3

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

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.

Comment 4

[Graydon Hoare :graydon]

I'm not seeing this crash in the tinderboxes anymore. Is it still happening?

Comment 5

[Andrew Schultz]

Attachment: 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.

Comment 6

[Graydon Hoare :graydon]

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?

Comment 7

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

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.

Comment 8

[Graydon Hoare :graydon]

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. 

Comment 9

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

This looks like it's ok now on http://tinderbox.mozilla.org/SeaMonkey/ .  Marking worksforme; not sure when it was fixed.