DEBUG_CC is really crashy

RESOLVED WONTFIX

Status

()

P1
normal
RESOLVED WONTFIX
9 years ago
6 years ago

People

(Reporter: sayrer, Unassigned)

Tracking

unspecified
x86
Windows 7
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
This means no one is running it. I bet if they did, they'd find some problems with our cycle collection.
(Reporter)

Updated

9 years ago
blocking2.0: --- → final+
(Reporter)

Updated

9 years ago
Priority: -- → P1

Comment 1

9 years ago
DEBUG_CC massively changes the way CC works and the way we build the model. I am not sure its the right thing to do for anything but leak finding. But anyway, can you post a few stacks?
(Reporter)

Comment 2

9 years ago
(In reply to comment #1)
>
> not sure its the right thing to do for anything but leak finding. 

Yuh. we got some leaks. For instance, it looks like mrbkap forgot to add nsGlobalWindow.mInnerWindow to CC traversal.
(Reporter)

Comment 3

9 years ago
Created attachment 457492 [details]
a couple stacks

Comment 4

9 years ago
Don't get me wrong. I am all for leak detection. I am just saying the current DEBUG_CC output is nuts and not very useful for that.
Yes, it does mean no one is running it.

However, a bunch of it does exist for a reason, and fixing it is probably a lot less work than throwing it out and rewriting it.  Debugging complex leaks in cycle collection is a nontrivial task, and it makes a big difference in a bunch of cases.
I do run with DEBUG_CC and it didn't use to crash for me. The first stack looks like it's from the new compartments code?
Created attachment 475191 [details]
segfault at shutdown stack

I'm segfaulting at shutdown, which isn't so helpful.
How is that related to DEBUG_CC? It looks like sCollector is corrupt, I don't think we do anything different there if DEBUG_CC is defined.

Updated

8 years ago
blocking2.0: final+ → -
(Reporter)

Comment 9

8 years ago
now I'm getting 


###!!! ASSERTION: Didn't call FinishTraverse?: '!mCycleCollectionContext', file /home/sayrer/dev/mozilla-central/js/src/xpconnect/src/nsXPConnect.cpp, line 462
Assertion failure: CURRENT_THREAD_IS_ME(t), at /home/sayrer/dev/mozilla-central/js/src/jsapi.cpp:847


we actually need this to work to debug leaks, right?
OS: Mac OS X → Windows 7
What's the stack? I'm not seeing that on a trunk DEBUG_CC build.

I don't need this to debug leaks, I use the CC logs which work in any build. But I guess others might prefer the DEBUG_CC output.
(Reporter)

Comment 11

8 years ago
Created attachment 508156 [details]
calling XPCCallContext::~XPCCallContext on thread 19

Comment 12

8 years ago
We should do the explain live garbage stuff only from the main thread.
(Reporter)

Comment 13

8 years ago
(In reply to comment #10)
> What's the stack? I'm not seeing that on a trunk DEBUG_CC build.
> 
> I don't need this to debug leaks, I use the CC logs which work in any build.
> But I guess others might prefer the DEBUG_CC output.

How can I turn on those logs?

> (In reply to comment #12)
> We should do the explain live garbage stuff only from the main thread.

I don't see that happening in my stack. Am I mistaken?
RIP DEBUG_CC (bug 845441).  Plus I think I tore out the crashy stuff a year or so ago.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.