I started seeing this with the 0206xx builds. Download a talkback build for Windows (just tried 2001020804). Do a clean "install" by deleting all the Mozilla data directories and the moz*.dat files. Start the browser, go into Prefs and change the font default type from serif to sans serif. Choose OK. Crashes in GKHTML.DLL. Of course, now that I'm trying to enter the bug, it's not happening. But it's occured often enough the past few days that I'd like to put in a bug anyway.

good catch! this also happens on linux [2001.02.09.08 comm bits]. here's talkback data from the linux bits: Incident ID 26089797 Trigger Time 2001-02-09 19:36:32 Build ID 2001020908 0x08af16d2 StyleContextImpl::ShareStyleData() StyleContextImpl::RemapStyle() NS_NewStyleContext() StyleSetImpl::GetContext() StyleSetImpl::ResolvePseudoStyleFor() nsPresContext::ResolvePseudoStyleContextFor() nsComboboxControlFrame::CreateFrameFor() nsCSSFrameConstructor::CreateAnonymousFrames() nsCSSFrameConstructor::CreateAnonymousFrames() nsCSSFrameConstructor::ConstructSelectFrame() nsCSSFrameConstructor::ConstructFrameByTag() nsCSSFrameConstructor::ConstructFrameInternal() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ProcessChildren() nsCSSFrameConstructor::ConstructTableCellFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableRowFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableRowGroupFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableFrame() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrameInternal() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ProcessChildren() nsCSSFrameConstructor::ConstructTableCellFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableRowFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableRowGroupFrame() nsCSSFrameConstructor::TableProcessChild() nsCSSFrameConstructor::TableProcessChildren() nsCSSFrameConstructor::ConstructTableFrame() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrameInternal() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ProcessBlockChildren() nsCSSFrameConstructor::ConstructBlock() nsCSSFrameConstructor::ConstructFrameByDisplayType() nsCSSFrameConstructor::ConstructFrameInternal() nsCSSFrameConstructor::ConstructFrame() nsCSSFrameConstructor::ProcessChildren() nsCSSFrameConstructor::ConstructDocElementFrame() nsCSSFrameConstructor::ReconstructDocElementHierarchy() StyleSetImpl::ReconstructDocElementHierarchy() PresShell::ReconstructFrames() PresShell::SetPreferenceStyleRules() nsPresContext::PreferenceChanged() PrefChangedCallback() pref_DoCallback() pref_HashPref() PREF_SetCharPref() nsPref::SetCharPref() nsPref::SetUnicharPref() XPTC_InvokeByIndex() nsXPCWrappedNativeClass::CallWrappedMethod() WrappedNative_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x174db (0x406094db) libglib-1.2.so.0 + 0x10186 (0x40636186) libglib-1.2.so.0 + 0x10751 (0x40636751) libglib-1.2.so.0 + 0x108f1 (0x406368f1) libgtk-1.2.so.0 + 0x8c5b9 (0x4055e5b9) nsAppShell::Run() nsAppShellService::Run() main1()

cc'ing css folx. ideas why this is happening? also crashes mac [2001.02.09.08]: Incident ID 26090177 Trigger Time 2001-02-09 19:48:57 Build ID 2001020908 Platform ID MacOS Stack Trace 0xc10000fc StyleContextImpl::ShareStyleData() [nsStyleContext.cpp, line 4141] StyleContextImpl::RemapStyle() [nsStyleContext.cpp, line 3912] NS_NewStyleContext() [nsStyleContext.cpp, line 4627] StyleSetImpl::GetContext() [nsStyleSet.cpp, line 837] StyleSetImpl::ResolvePseudoStyleFor() [nsStyleSet.cpp, line 1011] nsPresContext::ResolvePseudoStyleContextFor() [nsPresContext.cpp, line 647] nsComboboxControlFrame::CreateFrameFor() [nsComboboxControlFrame.cpp, line 2228] nsCSSFrameConstructor::CreateAnonymousFrames() [nsCSSFrameConstructor.cpp, line 5156] nsCSSFrameConstructor::CreateAnonymousFrames() [nsCSSFrameConstructor.cpp, line 5113] nsCSSFrameConstructor::ConstructSelectFrame() [nsCSSFrameConstructor.cpp, line 4199]

i tried changing other style prefs, and found that i can crash the app when changing the monospace font [from the droplist]. happens all the time on Mac [same stack trace], sometimes happens on linux [somewhat diff trace, see below], but somehow not [yet] on winNT. Incident ID 26204941 Trigger Time 2001-02-12 13:34:10 User Comments changed monospace font [droplist] Build ID 2001020908 Platform ID LinuxIntel Stack Trace 0x00000006 StyleContextImpl::ShareStyleData() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() nsPresContext::RemapStyleAndReflow() nsPresContext::PreferenceChanged() PrefChangedCallback() pref_DoCallback() pref_HashPref() PREF_SetIntPref() nsPref::SetIntPref() XPTC_InvokeByIndex() nsXPCWrappedNativeClass::CallWrappedMethod() WrappedNative_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x174db (0x406094db) libglib-1.2.so.0 + 0x10186 (0x40636186) libglib-1.2.so.0 + 0x10751 (0x40636751) libglib-1.2.so.0 + 0x108f1 (0x406368f1) libgtk-1.2.so.0 + 0x8c5b9 (0x4055e5b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x402449cb)

I sure wish I could dup this - but I don't have a mac. I'd like to see where in ShareStyleData it is crashing... Pierre, can you dup this?

I can't reproduce it with my build (a pull from Feb 07). Sairuh, please describe the exact steps to reproduce. I'll update my tree if I still can't get the crash.

In an optimized build, with symbols, pulled about 1pm PST 02/08, I get this stack on the crash (using Modern skin if that makes a difference). Note: on one occasion, I didn't crash on the switch, but 3 other times I did. The steps are start browser (www.mozilla.org), Edit->Preferences..., go to Fonts panel, toggle radio button to sans-serif, click OK, crash. (Note, I am on a brand new profile if that makes a difference). StyleSetImpl::FindMatchingContext(StyleSetImpl * const 0x00000000, nsIStyleContext * 0x02a4c900, nsIStyleContext * * 0x0012d21c) line 1865 + 6 bytes StyleContextImpl::ShareStyleData(StyleContextImpl * const 0x00000001) line 4144 + 20 bytes StyleContextImpl::RemapStyle(StyleContextImpl * const 0x03f4c304, nsIPresContext * 0x027f6070, int 1) line 3915 StyleContextImpl::RemapStyle(StyleContextImpl * const 0x02a4c900, nsIPresContext * 0x027f6070, int 1) line 3920 StyleContextImpl::RemapStyle(StyleContextImpl * const 0x02a38890, nsIPresContext * 0x027f6070, int 1) line 3920 StyleContextImpl::RemapStyle(StyleContextImpl * const 0x02a2d340, nsIPresContext * 0x027f6070, int 1) line 3920 StyleContextImpl::RemapStyle(StyleContextImpl * const 0x028d65d8, nsIPresContext * 0x027f6070, int 1) line 3920 nsPresContext::RemapStyleAndReflow(nsPresContext * const 0x027f6070) line 344 nsPresContext::PreferenceChanged(nsPresContext * const 0x00000001, const char * 0x03fcb998) line 382 + 6 bytes PrefChangedCallback(const char * 0x03fcb998, void * 0x027f6070) line 72 pref_DoCallback(const char * 0x03fcb998) line 2259 + 10 bytes pref_HashPref(const char * 0x03fcb998, PrefValue {...}, int 32, int 1) line 1830 PREF_SetCharPref(const char * 0x03fcb998, const char * 0x0012da38) line 737 + 17 bytes nsPref::SetCharPref(nsPref * const 0x00b097c0, const char * 0x03fcb998, const char * 0x0012da38) line 841 + 13 bytes nsPref::SetUnicharPref(nsPref * const 0x00b097c0, const char * 0x03fcb998, const unsigned short * 0x040ec438) line 847 + 46 bytes XPTC_InvokeByIndex(nsISupports * 0x00b097c0, unsigned int 16, unsigned int 2, nsXPTCVariant * 0x0012dab4) line 139 ... [snip] ... And the code is here ... #ifdef USE_FAST_CACHE nsVoidArray *pList = nsnull; scKey key; aStyleContextToMatch->GetStyleContextKey(key); if (NS_SUCCEEDED(mStyleContextCache.GetContexts(key, &pList)) && pList) { PRInt32 count = pList->Count(); PRInt32 i; for (i=0; i<count;i++) { nsIStyleContext *pContext = (nsIStyleContext *)pList->ElementAt(i); if (pContext && pContext != aStyleContextToMatch) { PRBool bMatches = PR_FALSE; HERE-> NS_ADDREF(pContext); if (NS_SUCCEEDED(pContext->StyleDataMatches(aStyleContextToMatch, &bMatches)) && bMatches) { *aMatchingContext = pContext; rv = NS_OK; break; } else { NS_RELEASE(pContext); } } } } #else // DONT USE_FAST_CACHE

Eegads - it looks like something might be stomping on memory and corrupting the style context that is in the hash table, since we are crashing on a non-null AddRef. The Context Cache has not changed in a month or more, as far as I know.

Ok, I can reproduce it. I was playing with the popup menus, not the checkbox.

*** Bug 68752 has been marked as a duplicate of this bug. ***

*** Bug 68940 has been marked as a duplicate of this bug. ***

Does anybody have an idea what is happening here? Changing font prefs is hosed, and the dups are piling up, so I'm thinking that this should be getting some attention.

here's a testcase --sorry for the delay! 1. open Preferences dialog, select Fonts panel. 2. switch the Default Type radiobutton from Serif to Sans Serif [or, vice versa --just need to toggle the setting]. 3. click OK to dismiss Preferences dialog. result: crash. might need to repeat these steps once or twice, but you'll utlimately crash.

chatted w/mcafee, who sez he'll take this for now...

*** Bug 65445 has been marked as a duplicate of this bug. ***

*** Bug 69216 has been marked as a duplicate of this bug. ***

*** Bug 69096 has been marked as a duplicate of this bug. ***

*** Bug 69341 has been marked as a duplicate of this bug. ***

*** Bug 69085 has been marked as a duplicate of this bug. ***

crashes when modifying font prefs are gettin' common --adding mostfreq. here's the trace from bug 69085: Incident ID 26477281 Trigger Time 2001-02-16 21:14:45 User Comments Changed size of font more than once Build ID 2001021504 Platform ID LinuxIntel 0x00000003 StyleContextImpl::ShareStyleData() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() StyleContextImpl::RemapStyle() nsPresContext::RemapStyleAndReflow() nsPresContext::PreferenceChanged() PrefChangedCallback() pref_DoCallback() pref_HashPref() PREF_SetIntPref() nsPref::SetIntPref() XPTC_InvokeByIndex() nsXPCWrappedNativeClass::CallWrappedMethod() WrappedNative_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x16a12 (0x40652a12) libglib-1.2.so.0 + 0xf37f (0x4067c37f) libglib-1.2.so.0 + 0xf92b (0x4067c92b) libglib-1.2.so.0 + 0xfaa9 (0x4067caa9) libgtk-1.2.so.0 + 0x86e49 (0x405ade49) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x182e7 (0x4023f2e7)

*** Bug 69936 has been marked as a duplicate of this bug. ***

I think this bug occcurs when a new entry is added into user prefs.js. 1. make new user pref 2. change from a default value to a new value (add a new entry into prefs.js 3. CRASH, but the new entry is added. 4. restart mozilla, and change the value added 5. SUCCEED forever about the pref. I checked with mozilla-0.8 (my own build from source) on Linux. Checked Prefs: font-size, font-family(sans/serif), DPI, default bg color and papersize to print (in Printing Dialog)

add myself to the CC'list so that I can follow this bug, we think this is a ShowStopper for Asian languages Support because the default fonts setting is not enough, we need to change the fonts very often to view different encodings.

switching font.default to an int pref fixes this problem. problem in pref.SetUnicharPref() ?

attaching diff. I'd like to check this fix in and get with ben/etc. to file a bug re: SetUnicharPref().

new SetUnicharPref() bug filed to ben, bug 70254.

Look ok to me, as long as i18n doesn't have a hissy fit, r=pchen

fix checked in, this is now an int pref.

The fix was only for the front-end. I think you forgot the back-end. Reopening. Open a new bug if you wish. Look for font.default: http://lxr.mozilla.org/seamonkey/search?string=font.default

Reopening. See previous comment.

*** Bug 70214 has been marked as a duplicate of this bug. ***

yes, I screwed up, sorry. accepting. changes backed out.

Here's a stack trace, finally. gdb took 61 minutes to load libgkcontent.so, then another 20 to return the gdb prompt to me: #0 0x4142088c in StyleSetImpl::FindMatchingContext (this=0x42a0f740, aStyleContextToMatch=0x4287f468, aMatchingContext=0xbfffc180) at nsStyleSet.cpp:1870 #1 0x4141abe8 in StyleContextImpl::ShareStyleData (this=0x4287f468) at nsStyleContext.cpp:3681 #2 0x4141a323 in StyleContextImpl::RemapStyle (this=0x4287f468, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3449 #3 0x4141a363 in StyleContextImpl::RemapStyle (this=0x428cb180, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #4 0x4141a363 in StyleContextImpl::RemapStyle (this=0x42a42780, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #5 0x4141a363 in StyleContextImpl::RemapStyle (this=0x42a3de40, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #6 0x4141a363 in StyleContextImpl::RemapStyle (this=0x428a87a0, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #7 0x4141a363 in StyleContextImpl::RemapStyle (this=0x428a5af8, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #8 0x4141a363 in StyleContextImpl::RemapStyle (this=0x42877e98, aPresContext=0x420a7350, aRecurse=1) at nsStyleContext.cpp:3456 #9 0x41c90a4b in ?? () from /builds/mcafee/cmonkey/mozilla/dist/bin/components/libgklayout.so #10 0x41c90bf1 in ?? () from /builds/mcafee/cmonkey/mozilla/dist/bin/components/libgklayout.so #11 0x41c8f4b7 in ?? () from /builds/mcafee/cmonkey/mozilla/dist/bin/components/libgklayout.so #12 0x40abdcc4 in pref_DoCallback (changed_pref=0x8572ba8 "font.default") at prefapi.c:1740 #13 0x40abd0bb in pref_HashPref (key=0x8572ba8 "font.default", value={ stringVal = 0xbfffcee8 "sans-serif", intVal = -1073754392, boolVal = -1073754392}, type=PREF_STRING, action=PREF_SETUSER) at prefapi.c:1345 #14 0x40abb722 in PREF_SetCharPref (pref_name=0x8572ba8 "font.default", value=0xbfffcee8 "sans-serif") at prefapi.c:535 nsStyleContext.cpp:3682 // check if there is a matching context... result = mStyleSet->FindMatchingContext(this, &matchingSC); mStyleSet is whacked, rest of StyleContextImpl instance looks ok. It looks like pref string is coming in ok as far as I can tell. Pierre's landing happened a few days before this bug was filed, over to pierre for a look.

*** Bug 70624 has been marked as a duplicate of this bug. ***

Moving to mozilla0.8.1

*** Bug 69057 has been marked as a duplicate of this bug. ***

*** Bug 69057 has been marked as a duplicate of this bug. ***

*** Bug 69730 has been marked as a duplicate of this bug. ***

This is a topcrash for Mozilla 0.8 on Linux (showing up under the 0x00000000 stack signature). Adding topcrash keyword, M08 and [@ StyleContextImpl::ShareStyleData] for tracking. Here is the only talkback entry I found in today's report with any helpful user comments: 0x00000000 523905c6 line Build: 2001021504 CrashDate: 2001-02-27 UptimeMinutes: 13 Total: 13 OS: Linux 2.2.16-22smp URL: Comment: I attempted to turn off the "system colors" option in the colors section of the preferences in Messenger Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27001612 StackTrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27001612

*** Bug 71750 has been marked as a duplicate of this bug. ***

This is killing me. Is there really no progress on thsi top-crash mostfreq nsbeta1 regression? Well, after tomorrow I'll have some time to look at it, I hope.

Marc: if you want to look at it, you are welcome. I'm deep into bug 43457, I have changes everywhere in my tree and I may not have time to work on that one for moz0.8.1.

Moving to mozilla0.9

*** Bug 71513 has been marked as a duplicate of this bug. ***

With my local tree, which has the new memory model for the style contexts, I get the following assertion multiple times before it crashes: ###!!! ASSERTION: Failure to find any contexts at provided key!: 'PR_FALSE', file nsStyleSet.cpp, line 1627

I changed my background color (default colors is not checked) and now I can't startup/debug because I'm in assertion death (for the assertion Pierre mentions above). Before this, I crashed in CSS code (ShareStyleData I think). Marc--let me know if you have a fix for this that you'd like me to check on Macintosh. Right now, this bug is interfering with me debugging another problem on Mac. :-(

I do not know what changed to break this - it was working fine when I checked it in and regressed months later. There is a bug on the assertions: bug 71598 - it is directly related to this bug and should probably be marked a duplicate. I have no fix for this, I have not even looked into it. I'd recommend commenting out the assertion for now since apparently it works fine once the assertions are done (see bug 71598).

*** Bug 71598 has been marked as a duplicate of this bug. ***

We can recreate this easy on OS/2. After the first two assertions, we trap in Frame Manager. I attached a patch to fix the trap. If the trap doesn't happen, things seem to run OK. You get twenty or thirty assertions shutting down though. All seem related to failed style lookup in the hash table.

*** Bug 73218 has been marked as a duplicate of this bug. ***

We found more crashes despite my small workaround. In StyleSetImpl::FindMatchingContext at the NS_ADDREF for pContext. Basically it looks like the style cache is getting corrupted. We found that turning off USE_FAST_CACHE (turned on in December) fixes the asserts and the crashes. We might want to do this for 0.8.1

Turning off the fast cache because something is stomping on it seems like a big mistake. If you do that, you might as well turn off style sharing because it will get very slow. We are better off finding the cause of the memory corruption.

*** Bug 73378 has been marked as a duplicate of this bug. ***

I've just hit this in the Solaris version. It bites me when I change font size for fixed-width fonts while displaying a CSS'd table in which one cell holds a <PRE> tag, and that cell is determining the width of its column in the table. The <PRE> tag is styled with font-size: smaller. Interestingly, the crash only happens when decreasing the size of the base font to 14pt after first increasing to 16pt; i.e. if I cancel out the effect of the styling with the preferences, it's cool, but if I then relax prefs to let the small-font styling show, then it dies screaming. Here's the tail of my stack-trace: CallWrappedMethod__23nsXPCWrappedNativeClassP9JSContextP18nsXPCWrappedNativePC25XPCNativeMemberDescriptorQ223nsXPCWrappedNativeClass8CallModeUiPlT6 (0x21af98, 0x3f94f8, 0xb06bd8, 0x249580, 0xffbec57b, 0x2) 0xff223908(0x88468, 0x90, 0x2, 0xffbec5b0, 0x11, 0x0) SetIntPref__6nsPrefPCci(0x88468, 0xc79130, 0xe, 0x4da5b0, 0x5aa490, 0xfe3def38) PREF_SetIntPref(0xc79130, 0xe, 0x2, 0x2, 0x2, 0x8) pref_HashPref(0x1, 0xe, 0x40, 0x1, 0xfcb4dbf8, 0x0) pref_DoCallback(0xc79130, 0xe, 0x40, 0x0, 0x402c0000, 0x0) PrefChangedCallback__FPCcPv(0xc79130, 0x9cb500, 0xfc5e2ed4, 0xffbec378, 0xfcb5555c, 0x2) PreferenceChanged__13nsPresContextPCc(0x9cb500, 0xc79130, 0xff1616f8, 0xb458fc, 0xffbec760, 0xff092468) RemapStyleAndReflow__13nsPresContext(0x9cb500, 0xfc5e3e60, 0x9a8f08, 0x9d0a90, 0x6e007074, 0x6e000000) RemapStyle__16StyleContextImplP14nsIPresContexti(0x877670, 0x9cb500, 0x1, 0xfcf39e04, 0xfc525e28, 0x0) RemapStyle__16StyleContextImplP14nsIPresContexti(0x6944e0, 0x9cb500, 0x1, 0xfcf39e04, 0xfce6130c, 0xfe3def38) RemapStyle__16StyleContextImplP14nsIPresContexti(0x6400f8, 0x9cb500, 0x1, 0xfcf39e04, 0x1, 0x5a7118) RemapStyle__16StyleContextImplP14nsIPresContexti(0x5889a8, 0x9cb500, 0x1, 0xfcf39e04, 0x1, 0x7d5a00) RemapStyle__16StyleContextImplP14nsIPresContexti(0x6cf330, 0x9cb500, 0x1, 0xfcf39e04, 0x1, 0x757d50) RemapStyle__16StyleContextImplP14nsIPresContexti(0x9becf8, 0x9cb500, 0x1, 0xfcf39e04, 0x1, 0x879a60) RemapStyle__16StyleContextImplP14nsIPresContexti(0x70abc8, 0x9cb500, 0x1, 0xfcf39e04, 0x1, 0x6d29c8) ShareStyleData__16StyleContextImpl(0x70abc8, 0x9cb500, 0xfcf3a6d4, 0x0, 0x1, 0x8779c0) 0xbf3474(0x5bd3c8, 0x70abc8, 0xffbeb484, 0xfcf3e378, 0x1, 0x7a8c40)

I just got this crash again when I checked the Colors panel's "Use system color" checkbox on my Mac build. Pierre--I'd be happy to test a patch if you have one.

using win32 mtrunk installer build 2001040522 on win95 system. attempting to switch default font type from serif to sans serif caused a *total shutdown* of my computer. one second the computer's on, the next second it's off. i'd suggest dataloss keyword if only because it interrupted my e-mail download and lost all the clusters.

I think I have a fix for this - taking it.

... like bug 73553 I think. Patch there fixes this too.

Patch in 73553 fixes this one too.

*** Bug 74740 has been marked as a duplicate of this bug. ***

Adding M081 and [@ StyleSetImpl::FindMatchingContext] to summary for tracking, since the StyleSetImpl::FindMatchingContext crash is a topcrasher for Mozilla 0.8.1 and was marked a dup of this one.

Generalzing summary: there are several prefs that can be changed to cause this same problem, and it will die in the same general area. What is the M081 for? Isn't that past now?

marc, the talkback team keeps track of progress on topcrash bugs over different releases, so M081 just means that it was (or still is) a problem with Mozilla 0.8.1. i also added Trunk to the summary since this looks like a crash that continued with the latest builds even after M081 was released.

M081 in the title of the this bug is just used to indicate that what is where we saw lots of users reporting crashes with this stack trace.

*** Bug 75461 has been marked as a duplicate of this bug. ***

*** Bug 59544 has been marked as a duplicate of this bug. ***

*** Bug 75662 has been marked as a duplicate of this bug. ***

Fix checked in under bug 73553

vrfy fixed [test: changed the font name and size] using 2001.04.18.0x comm verif bits on linux, winnt and macos. pls do reopen if anyone still sees this with a recent build!

*** Bug 73858 has been marked as a duplicate of this bug. ***

*** Bug 77921 has been marked as a duplicate of this bug. ***

patty, you added a comment in bug 68752 that this is still happening for you on Mac. jrgm, i vaguely recall that you had encountered [or, were you just asking about] this bug recently? could either of you pls reopen this if appropriate? thx!

The bug I was referring to is bug 77779, which crashes on the same user action, but it turns out that the crash is due to a cause (or code path) different from what was reported here.

The problems I saw earlier seem to be fixed now.

*** Bug 79042 has been marked as a duplicate of this bug. ***

*** Bug 81675 has been marked as a duplicate of this bug. ***