291210 - chatzilla is pretty broken with TOO_MUCH_GC

Status: RESOLVED WORKSFORME

(Other Applications :: ChatZilla, defect)

Description

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

When I define TOO_MUCH_GC at the top of jsgc.h and try to run Chatzilla, it's
pretty broken.  (I ran into this debugging bug 290535, but was able to find the
problem pretty easily without TOO_MUCH_GC.)  That means there's probably some
case where it really would be broken if it happens to run.

When I start Chatzilla with TOO_MUCH_GC:
 * I get an OK/Cancel dialog with no text
 * then I get the chatzilla UI with a bunch of the toplevel menus missing.

(There's a slight chance this could be related to changes in my tree, actually, 
but I don't think so.)

Assigning to myself to investigate, but it's low priority for me, so feel free
to take it if you can investigate.

Comment 1

[James Ross]

Purely from an academic point of view, how can running GC more agressively
actively break a managed application?

Back in reality; the dialog you get may well be the "oops, there was an error
starting ChatZilla" dialog, which is shown in the most unceremoniously way I
could come up with, here:
  http://lxr.mozilla.org/mozilla/source/extensions/irc/xul/content/handlers.js#53

Getting a log of all JS errors/warnings during startup obviously wouldn't hurt. :)

Comment 2

[timeless]

well, generally it means that an object which was created wasn't rooted before
it was used, which means it could be garbage collected and then you should crash.

i've seen the alert with no text, i think i actually know what that is, i should
be able to fix it.

i believe i've actually seen the problems dbaron describes. from memory, venkman
is worse, you just get the os border.

fwiw (to anyone not originally cc'd to the bug, since i believe the original
cc's/reporter all know this stuff), it's of course possible to dig through
cx->fp->down(*)->script[!=0]->filename/lineNo to get simplistic stack traces.

venkman at least, and probably chatzilla tend to play games with threads, and
most of their games are wrong (i have some patches, but they're nowhere near
finished, some are to js, and a couple are to jsd/xpc). unfortunately i'm fairly
distracted (as is dbaron).

Comment 3

[timeless]

oops, i was trying to say that it *shouldn't*, and they're mostly bugs in the
host and not the impl (with the exception of things which try to access
properties of say dom [global] window object from other threads).

Comment 4

[James Ross]

I didn't understand comment 3 at all, but from comment 2 it *sounds* like the
problem is with the host app... of course, the DOM is nice and thread-safe.
*cough* ;)

Aw hell, /me goes to make a TOO_MUCH_GC build...

Ok, that flag is lethal. :)

00 gklayout!nsDOMClassInfo::MarkReachablePreservedWrappers(class nsIDOMNode *
aDOMNode = 0x030c2164, struct JSContext * cx = 0x02642450, void * arg =
0x00000000)+0xc6 (CONV: cdecl)
[m:\source-head\mozilla\dom\src\base\nsdomclassinfo.cpp @ 4571]
  pwe->wrapper points to abababab/abababaf. :)

Comment 5

[James Ross]

Ok, so it turns out the blank window is the common dialog - which also appears
when I start a browser window. I believe it is the slow script dialog, but I
can't be sure.

I can see two JS errors from startup:
  JavaScript error: chrome://global/content/bindings/tabbox.xml, line 196:
this._resyncAttrs is not a function
  JavaScript error: chrome://chatzilla/content/handlers.js, line 45: client.deck
has no properties

I'm not sure why ChatZilla's startup seems to just die without error, but it may
be due to the slow script (if that is what it is) dialog being completely hosed.

Comment 6

[timeless]

that should be bug 290535

Comment 7

[James Ross]

As I suspected originally, ChatZilla is fine under TOO_MUCH_GC; it is only the slow script dialog that messes up, and that's fixed now anyway. I (slowly) connected to Moznet and joined #chatzilla with ChatZilla running on TOO_MUCH_GC just now, and nothing went wrong (unless you count the 15 minutes of CPU time it took on my 2GHz box).