It's #3 top crasher in 20.0a2 on Mac OS X and doesn't happen in Nightly. Signature mozalloc_abort(char const*) | NS_DebugBreak_P | mozilla::plugins::PPluginScriptableObjectChild::CallGetParentProperty(mozilla::plugins::PPluginIdentifierChild*, mozilla::plugins::Variant*, bool*) More Reports Search UUID 5938473e-65a3-42dd-8bf7-fc78e2130208 Date Processed 2013-02-08 23:48:28 Process Type plugin Java Applet Plug-in Version:14.5.0 Filename: JavaAppletPlugin.plugin Uptime 39 Install Age 1.9 hours since version was first installed. Install Time 2013-02-08 21:55:19 Product Firefox Version 20.0a2 Build ID 20130208042018 Release Channel aurora OS Mac OS X OS Version 10.8.2 12C60 Build Architecture amd64 Build Architecture Info family 6 model 58 stepping 9 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x0 App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x fc1GL Context? GL Context+ GL Layers? GL Layers+ Processor Notes sp-processor09.phx1.mozilla.com_4846:2008; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID 0x10de Adapter Device ID 0x fc1 Frame Module Signature Source 0 libmozalloc.dylib mozalloc_abort mozalloc_abort.cpp:30 1 XUL NS_DebugBreak_P nsDebugImpl.cpp:422 2 XUL mozilla::plugins::PPluginScriptableObjectChild::CallGetParentProperty PPluginScriptableObjectChild.cpp:576 3 XUL mozilla::plugins::PluginScriptableObjectChild::ScriptableGetProperty PluginScriptableObjectChild.cpp:232 4 XUL mozilla::plugins::child::_getproperty PluginModuleChild.cpp:1423 5 JavaAppletPlugin JavaAppletPlugin@0x24a8 6 JavaAppletPlugin JavaAppletPlugin@0x1fbc 7 JavaAppletPlugin JavaAppletPlugin@0x26bb 8 XUL mozilla::plugins::PluginInstanceChild::UpdateWindowAttributes PluginInstanceChild.cpp:3207 9 XUL mozilla::plugins::PluginInstanceChild::DoAsyncSetWindow PluginInstanceChild.cpp:2823 10 XUL mozilla::plugins::PluginInstanceChild::RecvAsyncSetWindow PluginInstanceChild.cpp:2723 11 XUL mozilla::plugins::PPluginInstanceChild::OnMessageReceived PPluginInstanceChild.cpp:1710 12 XUL mozilla::plugins::PPluginModuleChild::OnMessageReceived PPluginModuleChild.cpp:807 13 XUL mozilla::ipc::AsyncChannel::OnDispatchMessage AsyncChannel.cpp:473 14 XUL mozilla::ipc::RPCChannel::OnMaybeDequeueOne RPCChannel.cpp:402 15 XUL RunnableMethod<mozilla::ipc::RPCChannel, bool tuple.h:383 16 XUL MessageLoop::DeferOrRunPendingTask message_loop.cc:333 17 XUL MessageLoop::DoWork message_loop.cc:441 18 XUL base::MessagePumpCFRunLoopBase::RunWorkSource message_pump_mac.mm:291 19 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 20 CoreFoundation __CFRunLoopDoSources0 21 CoreFoundation __CFRunLoopRun 22 CoreFoundation CFRunLoopRunSpecific 23 HIToolbox RunCurrentEventLoopInMode 24 HIToolbox ReceiveNextEventCommon 25 HIToolbox BlockUntilNextEventMatchingListInMode 26 AppKit _DPSNextEvent 27 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 28 AppKit -[NSApplication run] 29 XUL base::MessagePumpNSApplication::DoRun message_pump_mac.mm:677 30 XUL base::MessagePumpCFRunLoopBase::Run message_pump_mac.mm:213 31 XUL MessageLoop::Run message_loop.cc:215 32 XUL XRE_InitChildProcess nsEmbedFunctions.cpp:494 33 plugin-container main MozillaRuntimeMain.cpp:48 More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P+|+mozilla%3A%3Aplugins%3A%3APPluginScriptableObjectChild%3A%3ACallGetParentProperty%28mozilla%3A%3Aplugins%3A%3APPluginIdentifierChild*%2C+mozilla%3A%3Aplugins%3A%3AVariant*%2C+bool*%29

This looks like the same issue behind bug 824069: Moving Java OOP intermittently triggers a Java bug where it doesn't seem to handle re-entering NPP_SetWindow() properly.

gfritzsche, why do you think that? The stack in comment 0 doesn't indicate problems with reentry: the actual error appears to be a fatal abort when we're receiving a reply from the parent at FatalError("Error deserializing 'bool'");

Hm, sorry, i guess i jumped to conclusions.

I forgot to mention it on this bug here: This is only happening with Java being OOP (bug 823559). That bug is on the train for 20, but will be backed out once it hits beta so we have another cycle for the investigation of the issues it caused.

Bug 823559 got backed out on beta.

(In reply to Georg Fritzsche [:gfritzsche] from comment #5) > Bug 823559 got backed out on beta. Are we planning on performing the backout on Aurora as well ? I see 823559 has many unresolved dependencies. In addition, I do not see this particular crash on crash-stats for 21.0a1 yet, so no need to track here in that case.

No, we are not planning on backing out of Aurora. Flipping Java back in-process turns various tests perma-orange.

(In reply to bhavana bajaj [:bajaj] from comment #6) > In addition, I do not see this particular crash on crash-stats for 21.0a1 > yet, so no need to track here in that case. Interestingly this is still not seen in 21 or 22, probably best to keep an eye on it for now.

(In reply to Georg Fritzsche [:gfritzsche] from comment #8) > Interestingly this is still not seen in 21 or 22 There are only 24 ADU on Mac in 21.0a2. > Whiteboard: [closeme 2013-04-25] Which patch will fix it in Nightly?

(In reply to Scoobidiver from comment #9) > (In reply to Georg Fritzsche [:gfritzsche] from comment #8) > > Interestingly this is still not seen in 21 or 22 > There are only 24 ADU on Mac in 21.0a2. Right, that would explain it. > > Whiteboard: [closeme 2013-04-25] > Which patch will fix it in Nightly? None as of yet - my intention was to keep track on this if there are no further reports as there is not enough information in the stacks alone.

There are only two crashes over the last week both in 20.0a2 so not a top crasher.

This might also be

(In reply to Georg Fritzsche [:gfritzsche] [at Performance work-week] from comment #12) > This might also be ... fixed by 849613, so let's keep an eye on it.

(In reply to Georg Fritzsche [:gfritzsche] [at Performance work-week] from comment #13) > (In reply to Georg Fritzsche [:gfritzsche] [at Performance work-week] from > comment #12) > > This might also be > ... fixed by 849613, so let's keep an eye on it. That is bug 831768, sorry :(

(In reply to Georg Fritzsche [:gfritzsche] from comment #14) > That is bug 831768, sorry :( I doubt it has fixed those crashes as they completely stopped in 20.0a2/20130214. There are no crashes in branches 21 and 22.