Closed Bug 674814 Opened 13 years ago Closed 13 years ago

Start up crash from Session Restore when Add-ons Manager is one of the restored tabs

Categories

(SeaMonkey :: General, defect)

defect
Not set
blocker

Tracking

(seamonkey2.3 affected, seamonkey2.4 affected, seamonkey2.5 affected)

RESOLVED WORKSFORME
Tracking Status
seamonkey2.3 --- affected
seamonkey2.4 --- affected
seamonkey2.5 --- affected

People

(Reporter: therubex, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [Sm2.3 affected][Sm2.4 affected])

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 Build ID: 20110706120824 Steps to reproduce: Start up crash from Session Restore when Add-ons Manager is one of the restored tabs New Profile Start SeaMonkey Open a second tab, about:addons Quit Restart SeaMonkey Actual results: Crash on start up Expected results: No crash First report: https://crash-stats.mozilla.com/report/index/bp-a744f908-18c1-4395-9e27-008782110727 Last (of a long line of) reports (unknown if different): https://crash-stats.mozilla.com/report/index/bp-bc7a2e59-1a7b-46b5-ad58-8de752110727 This does not occur in SeaMonkey 2.2 nor in Firefox 7.0a2.
> Quit That would be Quit, saving the session. This also affects SeaMonkey 2.3b1. https://crash-stats.mozilla.com/report/index/bp-f90a3e85-0d68-4dc6-81dc-0ec1b2110727
Version: Seamonkey 2.4 Branch → SeaMonkey 2.3 Branch
You can have two pages saved as your homepage; one of them being about:addons, & so long as Session Restore is not invoked, SeaMonkey loads successfully.
Severity: normal → blocker
(To be clear, I made the report on 2.2. I observed this on 2.4, then when back & checked 2.3 where this also occurs.)
Status: UNCONFIRMED → NEW
Crash Signature: [@ XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) ]
Ever confirmed: true
Keywords: crash
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110726 Firefox/8.0a1 SeaMonkey/2.5a1 ID:20110726003039 I see this on linux64 trunk too. Hard to tell if at the same point in the source because I have no symbols in libxul. (I have a few elsewhere, e.g. in libnspr, but that doesn't help.)
OS: Other → All
Whiteboard: [Sm2.3 affected][Sm2.4 affected]
Version: SeaMonkey 2.3 Branch → Trunk
CC Mossop in case he has any ideas (since this involves the Add-ons Manager)
It is interesting that SeaMonkey tries to restore session automatically after the first crash, which immediately results in a second crash, but then the about:sessionrestore is shown. I've noticed the behavior of automatic session restore even before with "regular" crashes - is this intended? Unselecting "Add-ons Manager" from the session restore page makes the session successfully restored without subsequent crash.
It was noted in #seamonkey that not everyone was seeing this, & indeed that is the case. Certainly repeatable on my Windows 7 box, but (checking now) not on my XP box? Seen on both Windows (at least 7) & Linux. Extensions are not an issue. Happens in a totally new Profile, in -safe-mode. Plugins are not likely an issue? Flash 10.3.181.34, I'm sure. Probably the wmpfirefoxplugin_1008 (port25).exe too, but I'd have to verify. No A/V or any other type of malware tools (realtime or otherwise). XP x86, Intel E4300, 2 GB RAM, NVIDIA GeForce4 MX 440 video. W7 x86, Intel i5-750, 4 GB RAM, (some other lowly video card, not sure offhand). In my case, XP is running Windows Classic theme. Windows 7 has "aero" turned off (not that I'm really sure what aero is/does, but my W7 looks as much like XP's Classic as I could reasonably make it.) Suppose I could try a different User account in W7 to see if I can dup it there too. Suppose some other (Windows) application I'm running could be contributing, but that would not explain those seeing it in Linux?
Comment 8 is likely wrong. What I believe happened is that this is now WFM. Works: Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110803 Firefox/7.0a2 SeaMonkey/2.4a2 http://hg.mozilla.org/releases/mozilla-aurora/rev/4b51e77c121a Crashes: Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110802 Firefox/7.0a2 SeaMonkey/2.4a2 http://hg.mozilla.org/releases/mozilla-aurora/rev/e0521aa0fec0 http://hg.mozilla.org/comm-central/pushloghtml?startdate=2011-08-03&enddate=2011-08-04
Changes for THAT range is actually: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e0521aa0fec0&tochange=4b51e77c121a I'm not certain of the c-c changes with that top of my head, but looks like it would be none at all.
(In reply to therube from comment #9) > Works: > > Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110803 Firefox/7.0a2 > SeaMonkey/2.4a2 > http://hg.mozilla.org/releases/mozilla-aurora/rev/4b51e77c121a > > Crashes: > > Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110802 Firefox/7.0a2 > SeaMonkey/2.4a2 > http://hg.mozilla.org/releases/mozilla-aurora/rev/e0521aa0fec0 If that is correct, Callek's time range would suggest bug 673378, which is about a Canvas crash (is the AOM using Canvas?). The patch was checked into Aurora and Beta at the same time, so it should be in either 2.3b3 or 2.3. Can you check with 2.3b3? [Unfortunately we don't have Beta nightlies.]
....well almost, 673378 was checked in later than the cset it worked for therube. (It was my first guess though)
On my XP box, in Comment 8, I am running 2.3b3 - without crash. On my XP box, firing up an older 2.4 build (that I happened to have laying around), I crashed. Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110613 Firefox/7.0a1 SeaMonkey/2.4a1 BTW 2.3b2 crashes, 2.3b3 does not.
Just for clarity, http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=d66a5a76f6ba&tochange=f327eb465d32 is the list from 2.3b2 -> 2.3b3 /me goes to look for correlations in two lists
(In reply to Justin Wood (:Callek) from comment #14) > Just for clarity, > http://hg.mozilla.org/releases/mozilla-beta/ > pushloghtml?fromchange=d66a5a76f6ba&tochange=f327eb465d32 is the list from > 2.3b2 -> 2.3b3 > > /me goes to look for correlations in two lists Ok, if those ranges were correct (the earlier nightly->nightly on aurora and 2.3b2 to 2.3b3) then the changes that are left is the single push by bjacob for the ANGLE upgrade (Bug 675634) and (Bug 675625) ABSOLUTELY no idea how that would affect this though. But since its WFM now by the reporter, I'm going to mark it as WFM, if therube (or anyone) wants to verify that cset as the fix specifically. we can mark as fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I used to have that chash on linux64 trunk (see comment #5); I have worked around it by starting the browser with a blank page then loading my multitab homepage (which includes about:addons) manually. Next time I start SeaMonkey I'll change it back to "load my home page" to see if the problem is gone. (If it isn't I can always reverse the change, even after a crash, by setting browser.startup.page back to 0 in prefs.js while SeaMonkey is not running.)
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110810 Firefox/8.0a1 SeaMonkey/2.5a1 ID:20110810003133 I don't see the bug anymore, loading at browser startup a very multitab homepage (currently 160 tabs including about:addons) while previously with a similar homepage I used to crash near the end of startup. IOW I VERIFY the resolution inasmuch as it concerns Linux64 trunk.
You need to log in before you can comment on or make changes to this bug.