(In reply to Tony Mechelynck [:tonymec] from comment #0)
[...]
> After I report this bug, I'll try to start ChatZilla from an already running
> SeaMonkey, to see if it crashes.
[...]
It did: bp-5a596f7e-127a-48c1-989e-7ea742110812 — again with the same 3-level crash, and again with a SEGV violation at address zero.

In reply to comment #2: yes, starting cZ triggers the crash.
If you have the least idea where this bug belongs, feel free to move it. I filed it in cZ because:
ChatZilla => crash
no ChatZilla => no crash.

Created attachment 552800[details]
verbose log of Mercurial changesets in ancestors(bad) but not in ancestors(good)
These are the mozilla-central changesets generated (with verbose on) on the mozilla-central repo by "hg glog -r 'ancestors(f262c389193e) - ancestors(7871abb0e291)'" i.e. the verbose graph of changesets in the bad build not present in the good build.
I'm not sure how to determine the corresponding comm-central changesets but maybe they are not relevant for ChatZilla.

Created attachment 552812[details]
the same verbose log, with long lines reformatted
the same verbose log, with long lines reformatted to no more than 100 characters in the hope (not always vindicated) of making the result more legible.
Maybe this inspires some of you developers, me it doesn't. I'm now gonna try and test some hourlies in the hope of narrowing the regression range.

Have you tried before and after Firefox builds? It seems unlikely to be a comm-central-specific change that started the crashing.
According to the crash reports, the main thread is waiting on something and it is another thread which has crashed. What's really needed is a symboled stack trace, so people can see where libxul is actually crashing. Which I guess means someone needs to make a debug build.

(In reply to James Ross from comment #11)
> Have you tried before and after Firefox builds? It seems unlikely to be a
> comm-central-specific change that started the crashing.
>
> According to the crash reports, the main thread is waiting on something and
> it is another thread which has crashed. What's really needed is a symboled
> stack trace, so people can see where libxul is actually crashing. Which I
> guess means someone needs to make a debug build.
I'll try some Nightly nightlies, or if you can request a try-build with debug, I can test that.

Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812030744
Built from http://hg.mozilla.org/mozilla-central/rev/f262c389193e
ChatZilla did not crash when started up; however, it has much fewer startup actions (no autoconnects, no scripts, no auto-joins or -queries) than my usual SeaMonkey chatZilla, also it is a much simpler browser profile (much more like a new profile: fewer extensions, fewer tabs, fewer "user set" prefs in about:config). Now I'm making the cZ prefs in that Firefox profile more like what I use in SeaMonkey.

Created attachment 552869[details]
cZ customizations (testcase)
This is a .tar.gz archive containing the following:
czcrash/
czcrash/chatzilla/
czcrash/chatzilla/scripts/ the installed scripts
czcrash/chatzilla/scripts/joinint/
czcrash/chatzilla/scripts/joinint/init.js
czcrash/chatzilla/scripts/away-marker/
czcrash/chatzilla/scripts/away-marker/init.js
czcrash/chatzilla/scripts/ctcp-notification/
czcrash/chatzilla/scripts/ctcp-notification/init.js
czcrash/chatzilla/networks.txt the customized network definitions
czcrash/prefs.js the possibly relevant extensions.irc.* prefs
czcrash/chatzilla/ can be merged with your <profile>/chatzilla/ (you might not have customized scripts & networks at all, in which case there will be no conflicts).
czcrash/prefs.js has to be merged with your <profile>/prefs.js while the application (Firefox or SeaMonkey) is not running.

Silver: I see a lot of "JS Engine" patches between the "good" and "bad" builds. Any idea which (if any) of them could cause a crash at cZ startup? FWIW, I have a custom networks.txt, autoconnected networks, and some "well-known" scripts: the whole of that seems to be enough to produce the crash. See the attachments for details.

Okay so .tar.gz is just irritating but luckily looking at the stack has been enough to trivially reproduce the issue on my own build: connect to ircs://moznet. BOOM.
There's at least one cz: logged error related to SSL too.
I'll see what I can narrow down here.

There is an abort added by "74214 (be91fb29d950) Bug 674597 - abort if attempting to create an xpcom proxy for wrapped JS (r=bsmedberg)" for when GetProxyForObject is called on a wrapped JS object. The NSS SSL code is smacking in to that.
I imagine this relates to the CZ code setting transport.securityCallbacks = new BadCertHandler(), judging by the QI going on and the code around.

(In reply to Luke Wagner [:luke] from comment #22)
> The relevant patches have been backed out and the crashes should go away in
> tonight's nightly or the next.
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 ID:20110818030747
I can now indeed start ChatZilla on Firefox without crashing. I'll now try it with the latest SeaMonkey nightly.

Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 SeaMonkey/2.6a1 ID:20110818044401
Built from http://hg.mozilla.org/mozilla-central/rev/fb919f4fa210
No crash.
I'm setting this bug FIXED (not WORKSFORME) because after the above (collective) detective work I think I can say with reasonable confidence that this bug was fixed at changeset 5f0596a0b81e backing out a patch for bug 674597. For the same reason I'm adding a comment in bug 674597 about an easy test (thanks Silver) at comment #17 above.

Note

You need to
log in
before you can comment on or make changes to this bug.