Note: this bug-reports relate to bug 700835. It could seem that that fix broke stuff on Linux. My test-case is NemID, the national login system in Denmark (e.g. eboks.dk --> click "Log på privat"). It is a java applet. Cf. above the fix was pushed to Aurora on the 10th. I checked my build of Aurora from Nov 8. It works. The build from Nov. 11 crashed. More importantly, with the release of Fx10, this also crashes now. | 9.0a2-0.20111108 | + | |---------------------------------+---| | 10.0a2-0.20111111 | - | | Fri 11 Nov 2011 12:48:21 PM GMT | | |---------------------------------+---| +: works ; - crash This bug is also present in (a) Fx 10; (b) Aurora 12. I use Archlinux 64 bit with OpenJDK 6.b24_1.11 and icedtea 1.1.4. [Versions of JDK > 6 does not seem to work with NemID (in my case at least)]. The console output before crashing is: java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11) (ArchLinux-6.b24_1.11-1-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Feb 7, 2012 10:27:01 PM <WARN> DANID_DIGITAL_SIGNATUR appletdk.pbs.applet.bootstrap.new - Not using whitelisted class classloader: net.sourceforge.jnlp.runtime.JNLPClassLoader Feb 7, 2012 10:27:01 PM <INFO> Thread-4 - init Feb 7, 2012 10:27:01 PM <INFO> Thread-4 - selected loglevel: INFO Feb 7, 2012 10:27:01 PM <INFO> Thread-4 - This browser is a sun.applet.PluginAppletViewer[frame0,749,301,200x250,invalid,layout=java.awt.BorderLayout,title=,resizable,normal] Feb 7, 2012 10:27:02 PM <INFO> Thread-4 - start Assertion failure: rt->onOwnerThread(), at /build/src/mozilla-release/js/src/jsapi.cpp:6316 Aborted See also the Arch bug: https://bugs.archlinux.org/task/28235

Please try to narrow the regression range on the aurora branch further, so that it's no longer than one day. Please also find the (one day) regression range on the trunk (i.e. the mozilla-central "branch"). I'd be very surprised if my patch for bug 700835 has anything to do with this bug.

There is something about NemID going caching of its files differently. = It deletes its files or redownloads everything every single time. I don't recall exactly. It could actually just be related based on what your patch contains. Will do a test tomorrow if I remember

I can narrow it down further: | 9.0a2-0.20111108 | + | |---------------------------------+---| | 10.0a2-0.2011109 | - | I am afraid I've only got the packed builds, not the src-tree. In /usr/lib/aurora cat application.ini reveals [App] Vendor=Mozilla Name=Aurora Version=10.0a2 BuildID=20111109071722 ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384} Can the revision be identified from the ID? Is the revision stored somewhere in the tree ex post build? I can ask the maintainer of the Arch Aurora repo and see if I can get a hold of an older log, if that would be helpful.

> packed builds I don't know what these are. Please test with the nightlies at ftp://ftp.mozilla.org/pub/firefox/nightly/

> Please test with the nightlies I use Aurora 12.0a2. It is still a problem here. I will try nightly. >> packed builds > I don't know what these are. Packages. Think .deb.

Please do figure out how to test with the nightlies. Tests with anything else aren't much use to us. The most important nightlies to test with are the mozilla-central and aurora nightlies. I don't believe any of the nightlies are "packages" (deb or otherwise). To test with plugins you may need to add soft links to each nightly's "plugins" subdirectory.

I currently use Aurora 12a2 from http://pkgbuild.com/~heftig/repo/x86_64/?C=M;O=D > aurora-12.0a2-0.20120207-x86_64.pkg.tar.xz 07-Feb-2012 00:50 16M I will try with latest trunk from nightly, but I will have to compile, so it might take some time.

It also crashes Fx13a1 (just downloaded from http://ftp.mozilla.org/pub/firefox/nightly/latest-trunk) Crash-report: Add-ons: keysnail@mooz.github.com:1.9.4,{972ce4c6-7e08-4474-a285-3208198ce6fd}:10.0 BuildID: 20120207031136 CrashTime: 1328661654 EMCheckCompatibility: true FramePoisonBase: 7ffffffff0dea000 FramePoisonSize: 4096 InstallTime: 1328661559 Notes: OpenGL: Tungsten Graphics, Inc -- Mesa DRI Mobile Intel® GM45 Express Chipset -- 2.1 Mesa 7.11.2 -- texture_from_pixmap ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384} ProductName: Firefox ReleaseChannel: nightly SecondsSinceLastCrash: 15 StartupTime: 1328661643 Theme: classic/1.0 Throttleable: 1 URL: https://www.nemadgang.dk/nemid/login.aspx Vendor: Mozilla Version: 13.0a1 This report also contains technical information about the state of the application when it crashed. Here is the output to the terminal just before crash Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading items [dk.pbs.applet.bootstrap.synchronized@4e2f2295, dk.pbs.applet.bootstrap.synchronized@78878c4c, dk.pbs.applet.bootstrap.synchronized@b0c0f66, dk.pbs.applet.bootstrap.synchronized@44c6f734, dk.pbs.applet.bootstrap.synchronized@628f9a32, dk.pbs.applet.bootstrap.synchronized@41d47b2b] Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading OpenLogon2 Feb 8, 2012 12:40:53 AM <INFO> Thread-4 - start Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin OpenLogon2 correctly Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading bc Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin bc correctly Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading crypto Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin crypto correctly Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading nanoxml Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin nanoxml correctly Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading shortterm Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin shortterm correctly Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - loading attachments Feb 8, 2012 12:40:53 AM <DEBUG> InstallerThreaddk.pbs.applet.bootstrap.if - Loaded plugin attachments correctly Assertion failure: NS_IsMainThread(), at /builds/slave/m-cen-lnx64-ntly/build/js/xpconnect/src/xpcprivate.h:3654

I wrote: > but I will have to compile, so it might take some time. I used pre-compiled version.

I can confirm this on Ubuntu 11.10. Last good nightly: 2011-11-07 First bad nightly: 2011-11-08 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=161c6106d787&tochange=81dedcc49ac0

> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=161c6106d787&tochange=81dedcc49ac0 The patch for bug 700835 wasn't landed in this range. Nor was it's followup patch (for bug 705931). So, as I expected, this bug is unrelated to either of these patches.

You are right, Steven. This was based on me not looking at wrong dates. . . Sorry about that. None the less, the problem is real. Would you like me to remove each commit individually and test or is there are 'smarter' way to do it? Thanks, Rasmus

Rasmus, I asked you to use nightlies to find the regression range on mozilla-central and the aurora branch. But now someone else has found the regression range on mozilla-central. You could try to find it on the aurora branch, but to do this you *must* use aurora branch nightlies, none of which is a deb package. If this is too much work, it's probably best to leave it to others. I'm now taking leave of this bug. I'm a Mac guy, and there's really nothing more I can do here.

> Would you like me to remove each commit individually and test or is > there are 'smarter' way to do it? I didn't at first realize that you're talking about finding which patch (on the trunk) in Virgil's range triggered this bug. Probably the best way to do this is to use "hg bisect". There's some information on this at https://developer.mozilla.org/en/Triaging_crash_bugs#Regression_windows.

This is an intentional crash - see bug 716167. In a nutshell, you can't use XPConnect off of the main thread anymore. The first round of this was bug 650411 (where we asserted this for the JSRuntime). Most calls into XPConnect touch the JSRuntime, but a few of them (apparently) don't. Luke, didn't we run into problems with IcedTea on bug 650411 too?

Yes, this is exactly bug 704249. Since the crash-stack contains GetSafeJSContext, the XPC assert is hitting right before the JS assert would have hit. The good news is that there seems to be an IcedTea patch (https://launchpad.net/bugs/927282) that will hopefully make its way out soon.