484499 - crash [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] [@ nsCSSCompressedDataBlock::MapRuleInfoInto] (Mac)

Reporter

Description

•

16 years ago

reported in german Fx forum by a user, as of now without any STR or further infos. bp-24a16f17-cd13-4355-adbf-69a002090320 Signature nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*) UUID 24a16f17-cd13-4355-adbf-69a002090320 Time 2009-03-20 05:49:56.486505 Uptime 20101 Product Firefox Version 3.1b3 Build ID 20090305152042 Branch 1.9.1 OS Windows NT OS Version 6.0.6001 Service Pack 1 CPU x86 CPU Info AuthenticAMD family 15 model 107 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x6b84f1d0 User Comments Processor Notes Frame Module Signature Source 0 xul.dll nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*) layout/style/nsCSSDataBlock.cpp:190 1 xul.dll nsRuleNode::WalkRuleTree(nsStyleStructID,nsStyleContext*,nsRuleData*,nsCSSStruct*) layout/style/nsRuleNode.cpp:1673 2 xul.dll nsRuleNode::GetBackgroundData(nsStyleContext*) layout/style/nsRuleNode.cpp:1400 3 xul.dll nsStyleContext::CalcStyleDifference(nsStyleContext*) layout/style/nsStyleContext.cpp:486 4 xul.dll nsFrameManager::ReResolveStyleContext(nsPresContext*,nsIFrame*,nsIContent*,nsStyleChangeList*,nsChangeHint) layout/base/nsFrameManager.cpp:1263 5 xul.dll nsFrameManager::ComputeStyleChangeFor(nsIFrame*,nsStyleChangeList*,nsChangeHint) layout/base/nsFrameManager.cpp:1563 6 xul.dll nsCSSFrameConstructor::RestyleElement(nsIContent*,nsIFrame*,nsChangeHint) layout/base/nsCSSFrameConstructor.cpp:10004 7 xul.dll nsCSSFrameConstructor::ProcessOneRestyle(nsIContent*,nsReStyleHint,nsChangeHint) layout/base/nsCSSFrameConstructor.cpp:13384 8 xul.dll nsCSSFrameConstructor::ProcessPendingRestyles() layout/base/nsCSSFrameConstructor.cpp:13491 9 xul.dll PresShell::DoFlushPendingNotifications(mozFlushType,int) layout/base/nsPresShell.cpp:4552 10 xul.dll PresShell::FlushPendingNotifications(mozFlushType) layout/base/nsPresShell.cpp:4510 11 xul.dll nsCSSFrameConstructor::RestyleEvent::Run() layout/base/nsCSSFrameConstructor.cpp:13576 12 xul.dll nsThread::ProcessNextEvent(int,int*) xpcom/threads/nsThread.cpp:510 13 xul.dll nsBaseAppShell::Run() widget/src/xpwidgets/nsBaseAppShell.cpp:170 14 nspr4.dll PR_GetEnv 15 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:87 16 firefox.exe firefox.exe@0x2197 17 kernel32.dll kernel32.dll@0x44910 18 ntdll.dll ntdll.dll@0x3e4b5 19 ntdll.dll ntdll.dll@0x3e488 from looking at the moduls one extension (ColorZilla.dll) is obvious (but relevant?).

Jesse Ruderman on Windows

Updated

•

16 years ago

Whiteboard: [needs stack evaluated for usefulness - style]

Boris Zbarsky [:bzbarsky]

Comment 1

•

16 years ago

Hard to say much from this stack. Line 190 in nsCSSDataBlock as of 3.1b3 is: 189 if (nsCachedStyleData::GetBitForSID(nsCSSProps::kSIDTable[iProp]) & 190 aRuleData->mSIDs) { So there's just bogus data somewhere here; hard to tell what. ColorZilla is a binary blob, so if extension compatibility was being overridden it might have just been completely breaking something. Who knows.

Jesse Ruderman on Windows

Updated

•

16 years ago

Status: NEW → RESOLVED

Closed: 16 years ago

Resolution: --- → INCOMPLETE

Janos Wild

Comment 2

•

16 years ago

I'm very much concerned and angry about this bug recently. I've found this bugreport page via a link on my crash report page. I've been experiencing this bug since last weekend, but let me explain this later. This computer I've been using mostly on weekends, and mostly avoided switching on during the summer. It's the Shiretoko I'm using and always the nightly build. My first crash report is dated back to June 6th. Until last week I've had a total of 17 crashes (12 in June, 1 in July and 4 in September). Yup, I haven't used it in August but I have in September! Explaining this is to see my point: I haven't had a lot of crashes. BUT! On 11th October, starting 15:55 CEST (UTC+2) till 20:29 I've experienced 12 crashes, all regarding this issue. Today from 19:47 to 23:44 (same timezone) I've had 28 crashes! And none of my browsing habits were changed. I think some code got included in a release that has installed on 11th October 15:55 CEST, making my browser crash far more often that it used to do. For debugging purposes I've disabled every addon except AdBlock, even plugins like Flash, but it didn't help. I can send you my crash report list if necessary. For example my latest is bp-b9d5cef4-4555-406e-9b6a-81cb22091016 I'm open for further questions or wishes to do this or do that. I won't change my config or files, but keep in mind, that I can submit answers on weekends.

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

Comment 3

•

16 years ago

What are you doing when the browser crashes? Does it crash on certain pages, or when you do certain things?

Janos Wild

Comment 4

•

16 years ago

Hard to tell. I was searching for a pattern, but failed to discover it. I was thinking of the Flash Player, but now completely uninstalled... It can't be. It crashes mostly when opening content in a new tab. No matter how many are still running - sometimes it's stable with 10-15, sometimes it crashes with 2 or even one. No certain pages are involved, it has crashed opening different pages.

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

Comment 5

•

16 years ago

I'm guessing all of these: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.5pre&platform=windows&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsCSSCompressedDataBlock%3A%3AMapRuleInfoInto%28nsRuleData*%29 are your crashes (since they're all the crashes with that signature on Firefox 3.5.5pre, and they have the same OS version and CPU type. One thing that's interesting is that in all cases, the stack has nsRuleNode::GetPositionData on it. That also seems to be true for the Firefox 3.5.3 crashes with this signature where the crash address is 0x40001 or 0x50001. I'm still not sure what that means, though. I suppose I should reopen this bug since it is showing up a decent amount in crash-stats.

Status: RESOLVED → REOPENED

Resolution: INCOMPLETE → ---

Jesse Ruderman on Windows

Updated

•

16 years ago

Whiteboard: [needs stack evaluated for usefulness - style]

Janos Wild

Comment 6

•

16 years ago

Yup, that can be mine... Service Pack is called in Hungarian "Szervizcsomag". Investigating the bug is your job, I'm not qualified for that :P But the date caught my attention: why are crashes more frequent since 11th of October? Do crash-stats show the same rise? I would look into the code that got added or modified that day... But wait a second! One of my crash reports from 2009-10-11 show that the build I was using was dated back to 20090926...! Unfortunately I can't have my other crash reports from that day processed, it would be great, if you could look around why. I've used my computer on these days only: 2009-09-18..20, 2009-09-27, 2009-10-11, 2009-10-16..18. Not knowing the results of my crashes of the 11th I can say the problem I'm experiencing is dated back to 26-27th of September...

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

Comment 7

•

16 years ago

We're getting 160 reports per week on Firefox 3.5.3, which was a build from August. And there were actually 340 reports per week back in mid-September. Could some other characteristic of your system have changed recently to cause this?

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

Comment 8

•

16 years ago

Er, sorry, it was 135 per week for Firefox 3.5.3 in mid-September (I mistakenly did a query for all versions rather than just 3.5.3).

Janos Wild

Comment 9

•

16 years ago

Janos Wild

Comment 10

•

16 years ago

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

Comment 11

•

16 years ago

Could you go to the url "about:config", type "extensions.enabledItems" into the "Filter:" box, and then right click on the line that shows up showing the "extensions.enabledItems" preference, select "Copy Value", and paste the result into this bug? That will show if you have any hidden addons installed, I think. (Firefox 3.6 isn't going to support hidden addons anymore.)

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

Comment 12

•

16 years ago

Actually... I don't need that, since there's a link rel="alternate" pointing to the JSON data from the crash report, which leads to things like: http://crash-stats.mozilla.com/dumps/5c5798be-6176-4ea3-a825-32b932091017.jsonz which contains: "addons": [["{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}", "1.1.1"], ["{972ce4c6-7e08-4474-a285-3208198ce6fd}", "3.5.5pre"]] The first one is Adblock Plus ( https://addons.mozilla.org/addon/1865 ). The second one is the default theme. So you don't have any hidden extensions.

Janos Wild

Comment 13

•

16 years ago

Hey David, Any progress?

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

Comment 14

•

16 years ago

No; if there were' you'd see it here. How much memory and swap does your system have? Is it possible the crash is a side effect of running out of memory?

Janos Wild

Comment 15

•

16 years ago

I don't think so. It also quits after fresh restart and opening one or two pages. I have hardly any program running, classic (grey) Windows theme in XP, so performance is my priority. By the way it as an Athlon XP 1700+ system with 640 MB SD RAM mainly used for browsing the internet. Virtual memory is set to custom size, beginning at 864 MB and possible maximum at 1728 MB. Suggested by the system is 958 MB. Should be far enough.

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

Comment 16

•

16 years ago

I just spent some time debugging the minidump from http://crash-stats.mozilla.com/report/index/321b29a6-dda5-4d12-8d33-31e142091106 which is somebody else's crash of the same form. in MapRuleInfoInto, the property in question is 'width' (0xac), the level is style eStyleAttr (5), and in the code: 191 void *prop = 192 nsCSSExpandedDataBlock::RuleDataPropertyAt(aRuleData, iProp); 193 switch (nsCSSProps::kTypeTable[iProp]) { 194 case eCSSType_Value: { 195 nsCSSValue* target = static_cast<nsCSSValue*>(prop); aRuleData is clearly correct (pointing to the correct value on the stack), iProp corresponds to 'width' (0xac), and yet we end up with |prop| being 0x50001. I have no idea how that could happen unless: (a) we jumped in from somewhere else in the middle, or (b) nsCSSExpandedDataBlock::kOffsetTable is somehow corrupt (c) we hit some sort of CPU bug Maybe I'll debug another at some point and see if it's similar.

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

Comment 17

•

16 years ago

http://crash-stats.mozilla.com/report/index/c17bcae2-c4e6-4c0c-9479-6457f2091105 looks pretty much exactly the same: property is 'width', aRuleData is good, except its level is 0x04 (eDocSheet) instead of eStyleAttrSheet.

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

Comment 18

•

16 years ago

http://crash-stats.mozilla.com/report/index/3dfb45f7-a25c-4276-ac70-c714f2091105 it's also width (0xac), level is 0x00 (eAgentSheet), and the resulting |prop| was 0x01 instead.

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

Comment 19

•

16 years ago

And in the crashes in comment 16 and comment 18, I checked that cursor and cursor_end looked fine. So I still have no idea what's going on here.

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

Comment 20

•

16 years ago

http://crash-stats.mozilla.com/report/index/0ac0dcd1-da87-4f3a-8808-a70f52091105 also has reasonable cursor and cursor_end, property width (0xac), level 0x04 (eDocSheet), and ends up with 0x40001. These have all been Firefox 3.5.4 crashes, though. I should probably look at some with a different version at some point.

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

Comment 21

•

16 years ago

Switching to Firefox 3.5.5: http://crash-stats.mozilla.com/report/index/0eb2e8cc-f05a-4a83-8891-f935d2091106 Now property is white-space (0xaa), and everything looks good until after the lookup in kOffsetTable. mLevel is 0x00. cursor and cursor_end look fine. kOffsetTable[0xaa] is at address 0x107d1a30 (and it occupies three words; it would be more likely the second or third being corrupted if they were); I should check if that matches the address from the Firefox 3.5.4 crashes. http://crash-stats.mozilla.com/report/index/26c9e466-f292-4d75-b8bc-0323a2091106 This time property is 0x60 (list-style-image), the cursors again look fine, mLevel is 0x04 (eDocSheet). kOffsetTable[0x60] is at 0x60a816b8. But the rule data has mMarginData non-null rather than aListData. So this one seems different. A question for Janos Wild: Do all of your crashes show up as this signature, or do you ever see other common ones?

Janos Wild

Comment 22

•

16 years ago

(In reply to comment #16) (c) Can't be a CPU bug, since that user uses Intel and I use AMD... (In reply to comment #21) I've sent you all my crash logs in #9 and #10. But yes, same signatures everywhere. Also yesterday they were: bp-713b679a-345f-4802-891d-640b42091106 2009.11.06. 23:28 bp-ab594cb3-e540-4b00-b36b-097b72091106 2009.11.06. 22:41 bp-5ac03961-3159-4149-9204-c78122091106 2009.11.06. 22:40 bp-a99ca592-5078-4d70-aebe-aab8a2091106 2009.11.06. 22:40 bp-27b4bbd3-91b1-4a13-ac2d-d60762091106 2009.11.06. 22:40 bp-6047b76c-75df-488d-aade-6930f2091106 2009.11.06. 22:40 bp-4ae4f39a-98f2-4173-bbdb-50e302091106 2009.11.06. 22:39 bp-5be42eff-b057-4725-ae9d-dec522091106 2009.11.06. 22:36 bp-391ed911-b773-4b60-adb2-8eb6a2091106 2009.11.06. 22:35 bp-486f8af4-2ae3-41fc-af63-3b2582091106 2009.11.06. 22:32 bp-e0c499bf-6c93-408f-b1c1-a5b0c2091106 2009.11.06. 22:32 bp-96949e03-d9af-4fd8-af8a-82dc82091106 2009.11.06. 22:32 bp-d77b1c10-aca3-4b78-8885-c1b0f2091106 2009.11.06. 22:31 bp-ffdaf9c2-5463-4b00-8340-190112091106 2009.11.06. 22:30 bp-b904c5e6-ed2a-4a3c-bff0-0be692091106 2009.11.06. 22:23 bp-7e83f407-283d-4434-9c81-dbebc2091106 2009.11.06. 22:14 bp-1f478a33-1f17-4af4-8945-f71382091106 2009.11.06. 22:06 bp-46c7352f-44bd-4a3c-9540-cb1592091106 2009.11.06. 22:03 Look at the timing. Two or three crashes within a minute...! But wait, those logs were posted from Firefox 3.5.5pre 20091023043835. And then I updated to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091106 Shiretoko/3.5.6pre. And NO CRASHES SINCE! I've been using it for almost 24 hours, multiple tabs, flash pages, sometimes heavy load. And Firefox stands the work. It is stable.

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

Comment 23

•

16 years ago

Well, that gives a range of http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-10-23+02%3A00&enddate=2009-11-06+06%3A00 . No ideas yet on what would be related. Please let us know if you see the crash again.

Robin Whittleton

Comment 24

•

15 years ago

I just had a crash with the same signature on Mac Fx4b7: http://crash-stats.mozilla.com/report/index/ea39f6e7-623f-47dc-9d26-403162101201

Wayne Mery (:wsmwk)

Updated

•

14 years ago

Severity: normal → critical

OS: Windows Vista → All

Summary: crash [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] → crash [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] [@ nsCSSCompressedDataBlock::MapRuleInfoInto] (Mac)

Nobody; OK to take it and work on it

Assignee

Updated

•

14 years ago

Crash Signature: [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] [@ nsCSSCompressedDataBlock::MapRuleInfoInto]

Wayne Mery (:wsmwk)

Updated

•

12 years ago

Blocks: 921728

Mats Palmgren (inactive)

Comment 25

•

7 years ago

nsCSSCompressedDataBlock is gone so it's not worth tracking these signatures anymore. Please file new bugs as appropriate.

Status: REOPENED → RESOLVED

Crash Signature: [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] [@ nsCSSCompressedDataBlock::MapRuleInfoInto] → [@ nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleData*)] [@ nsCSSCompressedDataBlock::MapRuleInfoInto]

Closed: 16 years ago → 7 years ago

Resolution: --- → INCOMPLETE