Closed Bug 872678 Opened 8 years ago Closed 8 years ago
Recent mozilla-central-debug nightlies crash visiting Robo
Hornet test site with OMTC on
If OMTC is on, today's and Monday's mozilla-central-debug nightlies crash immediately on visiting http://ie.microsoft.com/testdrive/Performance/RoboHornetPro/. You don't have to run the test (to click on "Start RoboHornet") to see the test. I tested on a Retina MacBook Pro running OS X 10.7.5. I turned on OMTC by changing the following settings: a) layers.offmainthreadcomposition.animate-opacity, true b) layers.offmainthreadcomposition.animate-transform, true c) layers.offmainthreadcomposition.enabled, true d) layers.offmainthreadcomposition.testing.enabled, true These crashes have already been reported (in a different context) at bug 676241 comment #47. But they have nothing to do with that bug. The Socorro crash logs are useless -- no symbols. And gdb crash stacks are also useless made from these builds, which have their symbols stripped. Later I'll do a custom build with symbols not stripped and post one or more gdb crash stacks.
The following are both enabled in mozilla-central-debug builds: ac_add_options --enable-trace-malloc ac_add_options --enable-accessibility But you still crash when you build without them.
> You don't have to run the test (to click on "Start RoboHornet") to see the test. You don't have to run the test to see the *crash*.
Here's the stack trace I promised. It was made with a custom build (of current trunk code), built using the following mozconfig options: ac_add_options --disable-strip ac_add_options --disable-install-strip ac_add_options --enable-debug ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk Interestingly I haven't yet been able to crash a non-opt debug build -- one built using the previous options plus the following: ac_add_options --disable-optimize
Attachment #750784 - Attachment description: All-thread gdb stack trace plus debug spew → All-thread gdb stack trace plus debug spew, opt build
Spoke too soon. Here's the results of a crash with a non-opt build. It was made with the following mozconfig settings: ac_add_options --disable-optimize ac_add_options --disable-strip ac_add_options --disable-install-strip ac_add_options --enable-debug ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk
Does this reproduce *without* the animate-* prefs enabled? These haven't been tested outside of mobile, and we aren't planning on enabling them for desktop just yet. Not trying to suggest that this isn't a real bug, just determining if this needs to block OMTC being enabled for OSX.
By the looks of things both threads can end up calling nsStyleTransformMatrix::TransformFunctionOf, and this is racing and causing the hash table to get confused about the recursion level. This shouldn't affect OSX immediately (since we aren't enabling OMT animations), but it seems very likely that mobile/b2g could hit this crash.
Crash Signature: [@ PL_DHashTableOperate | nsStaticCaseInsensitiveNameTable::Lookup(nsAString_internal const&) ]
> Does this reproduce *without* the animate-* prefs enabled? No. In fact I only see it if layers.offmainthreadcomposition.animate-transform is set. I don't see it with just layers.offmainthreadcomposition.animate-opacity set (of the two animate-* prefs). I also don't see the crashes with layers.offmainthreadcomposition.testing.enabled false -- even if the two animate-* prefs are set.
> I also don't see the crashes with > layers.offmainthreadcomposition.testing.enabled false -- even if the > two animate-* prefs are set. Oops, I take this back. The crashes are harder to reproduce without this set, but I did just see one.
Sometimes the crashes happen on quit.
nsStaticCaseInsensitiveNameTable::Init should probably call PL_DHashMarkTableImmutable at the end of the function. On top of that, CSS function storage should probably also use keywords rather than strings for the first field (the function name). It would use less memory and be more efficient. (It dates back to bug 435293, perhaps a mistake although I vaguely recall there may have been a reason for it.)
Comment on attachment 752072 [details] [diff] [review] Patch r=dbaron
Attachment #752072 - Flags: review?(dbaron) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #10) > On top of that, CSS function storage should probably also use keywords > rather than strings for the first field (the function name). It would use > less memory and be more efficient. (It dates back to bug 435293, perhaps a > mistake although I vaguely recall there may have been a reason for it.) Followup is bug 511803; I have a patch.
You need to log in before you can comment on or make changes to this bug.