Closed Bug 106596 Opened 23 years ago Closed 23 years ago

Crash after switching themes

Categories

(SeaMonkey :: Themes, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: petecoolrulez, Assigned: hewitt)

Details

(Keywords: crash)

I'm working on a theme, so I switch very often from theme to theme. After a few dozen switches (that's only an estimate), an error appears on startup after applying a new theme (but not every time; most of the time it does though): mozilla crashes with a seemingly random error message. Restarting Mozilla gives a functional browser with the newly selected theme. Here are two error samples. 1- The instruction at "0x0a0659d0" referenced memory at "0x0a0659d0". The memory could not be "read"(This form is the most occuring type, though the numbers change almost every time) 2- The exception Single Step A simgle step or trace operation has just been completed. (0x80000004) occurred in the application at location 0x0249d3ee. (I've got this one only once yet, while verifying if the bugs really happened repeatedly) All of this with build 0.9.5 (2001101117)
Reporter: Please try a more recent talkback-enabled build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip (as always, be sure to delete your old Mozilla directory before installing the new one) Then, if you get a crash, please post the Talkback ID here. (you can get the talkback id by running <moz-dir>/bin/components/talkback.exe) -> Critical -> Themes, but punt as needed
Assignee: asa → hewitt
Severity: major → critical
Component: Browser-General → Themes
Keywords: crash, stackwanted
QA Contact: doronr → pmac
I can repeat this (considering the crash happens randomly... after a few tries it will always crash) here using nightly 2001102503. I tried deleting my profile and creating a new one, with no positive results. Talkback ID is TB37201600W (I'm not fully sure I reported it right though - I'll try again if this one is useless; I "created a new incident" in talkback while the crashed mozilla process was still running, will that give the needed info?)
> I "created a new incident" in talkback while the crashed mozilla process was > still running, will that give the needed info? Not quite. If you're running a talkback-enabled build, the talkback program should trigger automatically when Mozilla crashes (as opposed to getting cryptic messages from Windows). Only after completing the talkback information do you need to run talkback.exe, and that's only so that you can get the Talkback ID.
The crash happens before the splash screnn ever appears, could that be why the talkback program never triggers on that crash?
So, is Mozilla actually crashing, or hanging? If it's only a hang, I'm not sure the developers can help much with that, without a reproducible testcase :-/.
Can you expand a little more of what is a crash vs a hang?
Sure. A crash is an unexpected program termination. Typically, you'll get Talkback popping up (or, a windows error dialog box if you don't have a talkback-enabled build). With a hang, Mozilla keeps running, but becomes unresponsive. It's still visible in Task Manager, possibly at a very-high CPU percentage.
This is still happening in 0.9.6 official build, it the same way. Stiil only a Windows error box, doesn't get to the splash screen, no trggering of talkback... is there any hope for this?
Without a reproducable testcase for the developers, I'm not sure what more can be done :-/. You could try a more recent build (see link in comment #1).
Reporter: Can you give us a testcase, or a URL to a page which tests for this?
This is the way it happens: First I install a theme (you can use mine [http://petecool.dyndns.org:81/mozilla/] for this case, though it happened with other themes with 0.9.4 and 0.9.5); when installing it, I uncheck "Use this theme". Then I go to the prefs and "apply" the new theme. I get told that it won't be applied until I restart mozilla; fine, I stop it and try to restart it. And there the crash happens, after I double-clicked the icon (or used the menu item, or pressed enter in "Run" - it doesn't matter at all, like would be expected); no splash screen, no hard disk noises indicating it's loading libraries and stuff, no talkback popping up, nothing but the error/crash dialog. Now, some more details. The crash doesn't ALWAYS happen at every try, but most of the time it does on my box. I don't NEED to install a new theme to make it happen, switching between Modern and Classic does it too, though I don't spend time doing that - the first paragraph tells exactly how I feel the problem most of the time. I think that's clearer, more detailed than my other posts...
Bug 116038 might be related or a dupe.
Pierre, if you are still able to crash this one with a recent trunk build (or M097), please do so. (Your old crashes have already been deleted from the database.) Post the Talkback ID in the bug, I will retreive the stack and we can see if this is a dupe of 116038. Thanks.
Hopefully I'm doing this right :) I have gotten this bug as well. It was on the full build I downloaded yesterday, 1-24-02 (build ID: 2001122106). It happens randomly when switching between classic and modern or vice versa. I am running Win2K pro. I have checked all the similar bugs with a "theme, crash" search and this is the bug that it matches exactly. I have yet to get a bug while browsing, so I have yet to see this "talkback" thing, but nothing comes up after the error message. If I re-click on the mozilla icon the program starts normally.
Confirmed crash in 2002012503 nightly build. Was not present in .9.5. TB ID is TB2140317Q. Can cause by doing View > Apply Theme > Theme Preferences, or via Edit > Preferences > Themes.
CC: stephend@netscape.com for talkback retrieval, please (TB2140317Q)
Keywords: stackwanted
Here's the stack for 2140317: nsBlockBandData::Init [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockBandData.cpp, line 72] nsBlockReflowState::nsBlockReflowState [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowState.cpp, line 148] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 735] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 846] nsBoxToBlockAdaptor::RefreshSizeCache [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 366] nsBoxToBlockAdaptor::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 573] nsSprocketLayout::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp, line 1521] nsContainerBox::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 595] nsBoxFrame::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1091] nsSprocketLayout::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp, line 1521] nsContainerBox::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 595] nsBoxFrame::GetAscent [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1091] nsSprocketLayout::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSprocketLayout.cpp, line 245] nsContainerBox::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 612] nsBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1198] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052] nsStackLayout::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsStackLayout.cpp, line 331] nsContainerBox::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 612] nsBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1198] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 991] nsRootBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsRootBoxFrame.cpp, line 243] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 776] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 574] PresShell::InitialReflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2674] nsXULDocument::StartLayout [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 4407] nsXULDocument::ResumeWalk [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 5946] nsXULDocument::OnStreamComplete [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6164] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 614] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 308] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1301] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1628] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1646] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08)
That's bug 121860, but that's not the bug originally reported here.
No. As I said, "that's not the bug originally reported here."
In that case, -> NEW?
I'm seeing this in 3-9-08 nightly w2k builds immediately after selecting a new theme from view > apply > theme. TB3846884Z, TB3846907Y FWIW, its possible that this related to the fix up with either crashing on the closing mozilla fix or crash upon changing two themes.. or the change to speed up window closing that when in to 3-9 builds.
cuz84d, if you are just starting to see crashes in theme switching, it is bug 129827 (recent regression) and not this one.
yup that would be the correct bug, not this one thanks. It was just build 3-9, not prior builds, nor build 3-10.
stack in comment 17 is the same as in bug 121860
It appears that the crash is occuring when changing the themes via Edit > Preferences. However, changing the themese via the View menu seems fine. I got verion 0.9.8 to crash in Windows2000 Sp2 ron_ladley@hotmail.com
BTW interactive theme switching in nightbuilds is now turned off. WORKSFORME?
Marking WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.