Crashes multiple time every day, no pattern found




9 years ago
8 years ago


(Reporter: Zeno-McDohl, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)



(1 attachment)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

I am getting crashes with Firefox multiple times every day. I don't see any pattern. Sometimes I'll be opening a new window and it'll crash, other times I'll be looking at a site and not doing anything and it'll crash.

This originally happened on v3.0.7 and continues to happen on the current version.

Here is an 8 page thread ruling out addons, themes, plugins, etc:

Reproducible: Always

Steps to Reproduce:
Actual Results:  

Expected Results:  
Not crashed.

bp-c2d7b6d0-8e3c-46a9-a81c-e731c2090916	[@ nsHTMLTokenizer::DidTokenize(int)‎ ]	9/16/2009	2:06 PM
bp-6484243c-4948-489a-b248-379ae2090915	[@ WrappedNativeMarker ]	9/15/2009	11:24 AM
bp-146e6db0-de11-4a5f-89f3-543402090914	[@ nsGlobalWindow::TimerCallback(nsITimer*, void*)‎ ]	9/14/2009	12:24 PM
bp-bb494df4-348c-4ee9-b129-66d9a2090914	[@ nsCycleCollector::CollectWhite()‎ ]	9/14/2009	12:12 PM
bp-f497467c-042c-40f7-9bed-f97552090914	[@ WrappedNativeMarker ]	9/14/2009	11:42 AM
bp-95f756d2-ed5d-462c-a6d4-863fa2090911	[@ @0x17b0 ]	9/11/2009	12:30 PM
bp-a744e561-99b5-48d7-9451-873782090910	[@ @0x737261 ]	9/10/2009	4:20 PM
bp-cf48203b-fa29-435f-8a3f-7a7552090910	[@ CloseNativeIterators ]	9/10/2009	4:19 PM
bp-c33960fc-aa5a-45cb-99dd-5481e2090908	[@ nsContentList::Match(nsIContent*)‎ ]	9/8/2009	1:25 PM


9 years ago
Version: unspecified → 3.5 Branch
do you have some example urls where this crash happens ?
Keywords: crash

Comment 2

8 years ago
I extracted the urls from the logs and gave them to Tomcat. These crashes are all over the map. I doubt they are all the same issue.

Comment 3

8 years ago
Chat support told me to try Shiretoko 3.5.4pre, still getting crashes in that. I was running that in safe mode today and got 2 crashes already:

bp-87c7f3fc-dcd6-4c8f-8c68-c8cff2091005	10/5/2009	11:53 AM
bp-4c137ca2-dc40-4c8d-a954-f0dbd2091005	10/5/2009	11:39 AM
"No proper signature could be created because no good data for the crashing thread (0) was found"

Comment 5

8 years ago
The second one has data, but strangely it is apparently a bug that was fixed half a year ago.

Comment 6

8 years ago
Went back to 3.5.3 in safe-mode, another crash:

Comment 7

8 years ago
6 crashes today.

acd2cb7d-8418-4a44-9bbe-365532091008	10/8/2009	3:40 PM
a1432bba-29ff-4055-b2dc-c66872091008	10/8/2009	3:22 PM
5dd585b6-b316-4b58-80b7-27b632091008	10/8/2009	2:06 PM
15cd3758-1f35-4001-bb4e-0623c2091008	10/8/2009	1:13 PM
05f8023c-e315-42d4-a45f-b7c302091008	10/8/2009	11:29 AM
e2b1dbf1-4c4d-454d-903b-d5bbd2091008	10/8/2009	10:58 AM
Many of these crashes involve cycle collector, so I suspect a thread-safety issue. On the other hand, your computer claims to only have one CPU core, which would make thread-safety issues unlikely to be hit.

Can you try browsing with a debug build, and see if there are any assertion failures before Firefox crashes?  Getting stack traces for assertion failures would bring us much closer to the root cause. says how, but:
* Use the "For a debug build..." part as your mozconfig, not the ">> mozconfig".
* Clone from instead of central.

Comment 9

8 years ago
Getting these errors on compile:

nsinstall: cannot copy g:\mozilla-1-9-1-b67fcb2d3fe5\mozilla-1-9-1-b67fcb2d3fe5\
ptionsui.js to ..\..\..\..\..\_tests\testing\mochitest\browser\browser\component
s\privatebrowsing\test\browser\browser_privatebrowsing_certexceptionsui.js: The
system cannot find the path specified.

nsinstall: cannot copy g:\mozilla-1-9-1-b67fcb2d3fe5\mozilla-1-9-1-b67fcb2d3fe5\
t_page.html to ..\..\..\..\..\_tests\testing\mochitest\browser\browser\component
s\privatebrowsing\test\browser\browser_privatebrowsing_geoprompt_page.html: The
system cannot find the path specified.

nsinstall: cannot copy g:\mozilla-1-9-1-b67fcb2d3fe5\mozilla-1-9-1-b67fcb2d3fe5\
transition.js to ..\..\..\..\..\_tests\testing\mochitest\browser\browser\compone
The system cannot find the path specified.

nsinstall: cannot copy g:\mozilla-1-9-1-b67fcb2d3fe5\mozilla-1-9-1-b67fcb2d3fe5\
tle_page.html to ..\..\..\..\..\_tests\testing\mochitest\browser\browser\compone
The system cannot find the path specified.

make[8]: *** [libs] Error 3
make[8]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[7]: *** [libs] Error 2
make[7]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[6]: *** [libs] Error 2
make[6]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[5]: *** [libs] Error 2
make[5]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[4]: *** [libs] Error 2
make[4]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[3]: *** [libs_tier_app] Error 2
make[3]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[2]: *** [tier_app] Error 2
make[2]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make[1]: *** [default] Error 2
make[1]: Leaving directory `/g/mozilla-1-9-1-b67fcb2d3fe5/mozilla-1-9-1-b67fcb2d
make: *** [build] Error 2

Comment 10

8 years ago
Someone in #developers told me to try a pre-compiled debug build. So I got

I can get it running, but when I try to visit another website it crashes with:

###!!! ASSERTION: no styles available in family "Fette Engschrift": 'mAvailableF onts.Length() != 0', file e:/builds/moz2_slave/mozilla-central-win32-debug/build /gfx/thebes/src/gfxWindowsFonts.cpp, line 289

I assume this is not the crash I'm getting, just something I'm missing for this to run?

Comment 11

8 years ago
that shouldn't be interesting.

explains how to ignore an assert, for that one, i think:
'Engschrift":' is what i'd use...

note that you should eventually find/file a bug for such things, but they aren't critical for the current task.

Comment 12

8 years ago
I don't see that registry path in my registry.

I'm getting a number of assert errors, far more crashes than I got normally:

###!!! ASSERTION: invalid BC damage area: 'PR_FALSE', file e:/builds/moz2_slave/
mozilla-central-win32-debug/build/layout/tables/nsTableFrame.cpp, line 3899

###!!! ASSERTION: painting in the middle of reflow: 'mPresContext->mLayoutPhaseC
ount[eLayoutPhase_Reflow] == 0', file e:\builds\moz2_slave\mozilla-central-win32
-debug\build\layout\base\nsPresContext.h, line 1177

###!!! ASSERTION: painting in the middle of reflow: 'mPresContext->mLayoutPhaseC
ount[eLayoutPhase_Reflow] == 0', file e:\builds\moz2_slave\mozilla-central-win32
-debug\build\layout\base\nsPresContext.h, line 1177

###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' pr
operty!: 'Error', file e:/builds/moz2_slave/mozilla-central-win32-debug/build/js
/src/xpconnect/src/xpcwrappednativescope.cpp, line 786

Comment 13

8 years ago
Just learned about set XPCOM_DEBUG_BREAK=warn, so now I can focus on running it and waiting for a crash. Didn't realize assertions weren't really crashes.

Comment 14

8 years ago
you have to create the path (if the wiki is unclear, please feel free to fix). the advantage of using the registry is that you can change your mind at any time and then stop for assertions.

Comment 15

8 years ago
Created attachment 410519 [details]
Debug log of Firefox running, eventually crashed

Comment 16

8 years ago
Okay, the debug build was running fine all yesterday so I think I have the build running just like what we want.

I had it running today for an hour and finally got a crash, which I assume it's the crash we're looking for. Attached the full debug log above.

Comment 17

8 years ago
###!!! ABORT: PresArena: poison overwritten: '*reinterpret_cast<PRUword*>(p) == ARENA_POISON', file e:/builds/moz2_slave/mozilla-central-win32-debug/build/layout/base/nsPresArena.cpp, line 171
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 3.5 Branch → Trunk
Zach, you might find comment 17 interesting.
I'm also interested in:

###!!! ASSERTION: painting in the middle of reflow: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_Reflow] == 0', file e:\builds\moz2_slave\mozilla-central-win32-debug\build\layout\base\nsPresContext.h, line 1177

It would be nice to have a stack for that, but I'm not sure how Zeno can get one.
I wonder if this is related to interaction with Microsoft Office Groove.  If it's not too much trouble, maybe try disabling or uninstalling that and see if it helps?
And I don't think there's any reason to think this is a Layout bug; it just seems like random memory corruption caused by something.
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.