Closed Bug 1092810 Opened 10 years ago Closed 2 years ago

startup Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ]

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 2.31 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: stefan_gies, Unassigned)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [startupcrash])

Crash Data

Attachments

(6 files)

Full Terminal output when launching SeaMonkey from the command line.
56.02 KB, text/plain
Details
FolderChangesView Report - SM 2.30
83.18 KB, text/plain
Details
FolderChangesView Report - SM 2.31
31.30 KB, text/plain
Details
FolderChangesView GUI Picture - SM 2.30
45.22 KB, image/png
Details
FolderChangesView GUI Picture - SM 2.31
22.21 KB, image/png
Details
localstore.rdf
1.22 KB, text/plain
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141030172027 Steps to reproduce: I installed Seamonkey v2.31 Beta 1 Build 1 An existing profile of Seamonkey v2.30 Final is used Actual results: After starting Seamonkey v2.31 Beta 1 Build 1 with the data of Seamonkey v2.30 the browser crashes. https://crash-stats.mozilla.com/report/index/7a3dd70f-b130-42ad-b3c9-3cbff2141102 Expected results: No error, using the old data
Starting Seamonkey v2.31 Beta 1 Build with a new profile works.
I'm experiencing this bug, too: https://crash-stats.mozilla.com/report/index/e2d20990-d6fa-4bab-b378-0102b2141103 I'm on OS X 10.8.5, so it's not Linux only. After playing with the -profilemanager and Safe Mode (start while pressing Option) options, it doesn't crash anymore and I cannot reproduce the issue. However, when I launch SM from the command line I get a bunch of "console.error", even if SM doesn't crash (I'm attaching a TXT file with the full Terminal output).
I should add that SM 2.31b1 resynced all my subscribed IMAP folders that were nested under another empty folder (it seems that local copy was wiped away) and that all Mail and Newsgroups' folders were collapsed.
Based on the crash signature this seems to be the same as Bug 1057581.
See Also: → 1057581
Crash Signature: [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) ] [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ]
Summary: Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 → Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ]
My crash: https://crash-stats.mozilla.com/report/index/326be4e8-df01-4a51-8a1d-aaad32141121 My notes, STR: new, clean profile. > that's not exactly correct > the Profile /name/ existed > though i emptied the Profile - entirely - nothing there > then i ... copied in existing places.sqlite - only. opened profile in SeaMonkey 2.26.1. verified that bookmarks were in place. > they were > checked by looking in the Sidebar (& left Sidebar open) Quit. opened same profile with SeaMonkey 2.31b1. Crash. And I've just duplicated those steps: https://crash-stats.mozilla.com/report/index/702c6e0c-ca59-473d-80d3-4e8cd2141121 A second attempt to open with SeaMonkey 2.31b1 succeeds, though bookmarks are wiped, which is Bug 1093623 - Bookmarks are lost when upgrade 2.31b1 from 2.30. Even though its marked above, See Also: I'll noting it again, kevin's Bug 1057581
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Odd. The STR I used in Bug 1093623 are essentially the same as with this bug. > this bug, existing places.sqlite from 2.30, then open 2.26, quit & open 2.31 > this results in a crash > opening an earlier version of SeaMonkey seems to be a prerequisite But, at the time of Bug 1093623, I did not crash, yet now I do & seemingly should have then too? (I'm on Win7 at the moment & think, though not sure, Win7 also with Bug 1093623?) OK, places.sqlite is immaterial. New STR. new profile, open in SeaMonkey < 2.31b1 Quit open SeaMonkey 2.31b1 Crash I have my normal, regular Profile open (this one I'm posting from) & would have started any others with the -no-remote switch, but that is typically how I always do things? 1093623 was from 11-4-2014, before MS's "second Tuesdays" updates, but I can't imagine anything in those had any effect, but who knows? > KB3003743 Security Update for Windows 7 for x64-based Systems (KB3003743) 11/11/2014 > KB3003057 Cumulative Security Update for Internet Explorer 11 for Windows 7 for x64-based Systems (KB3003057) 11/11/2014 > KB2993958 Security Update for Windows 7 for x64-based Systems (KB2993958) 11/11/2014 > Intel Corporation - Graphics Adapter WDDM1.1, Graphics Adapter WDDM1.2, Graphics Adapter WDDM1.3 - Intel(R) HD Graphics 4000 > 11/11/2014 11:39:16 PM AutomaticUpdates > KB2978125 Security Update for Microsoft .NET Framework 4 on Windows Server 2003, Vista, Windows 7, Server 2008, Server 2008 R2 x64 (KB2978125) 11/11/2014 > KB2991963 Security Update for Windows 7 for x64-based Systems (KB2991963) 11/11/2014 > KB3005607 Security Update for Windows 7 for x64-based Systems (KB3005607) 11/11/2014 > KB2992611 Security Update for Windows 7 for x64-based Systems (KB2992611) 11/11/2014 > KB2978120 Security Update for Microsoft .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2978120) 11/11/2014 > KB3010788 Security Update for Windows 7 for x64-based Systems (KB3010788) 11/11/2014 > KB3002885 Security Update for Windows 7 for x64-based Systems (KB3002885) 11/11/2014 > KB3008627 Update for Windows 7 for x64-based Systems (KB3008627) 11/11/2014 > KB3006226 Security Update for Windows 7 for x64-based Systems (KB3006226) 11/11/2014 Hmmm. The Graphics Adapter update that I put in. That could be interesting.
Aha, it's prefs.js! new profile, open in SeaMonkey < 2.31b1 Quit >> delete prefs.js open SeaMonkey 2.31b1 >> WORKS
Probably a bit more then that. A combination of prefs.js settings & some files existing or not existing during 2.31's first run, but I haven't put my finger on it yet? [Actually I did, but I've forgotten just what!!! After getting to the point where 2.31 was successfully opening, I forced it to crash, by... I think deleting pluginreg.dat & then copying over one or two prefs from a clean 2.30 Profile into the working 2.31 profile, & then on 2.31's startup, it crashed - but I've been screwing with so much, I don't remember the specifics & out of time ATM.] Comparing existing/non-existing files, first run of 2.30 vs 2.31, separate Profiles: + SiteSecurityServiceState.txt + xulstore.json Starting 2.31 using the 2.30 Profile (Crash occurs at this point): + pluginreg.dat Starting 2.31 using the 2.30 Profile (2nd attempt is successful): + sessionstore.bak Now delete pluginreg.dat & [... time for sleep]
Create new Profile (name only, directory empty at this point) Start up FCV & monitor... Profile loads Quit
Again start monitoring with FCV Start SeaMonkey 2.31, opening that same Profile CRASH. Quit
FWIW-^^ FolderChangesView - Monitor files changes on Windows http://www.nirsoft.net/utils/folder_changes_view.html FolderChangesView is a simple tool that monitors the folder or disk drive that you choose and lists every filename that is being modified, created, or deleted while the folder is being monitored.
I was able to avoid this crash by deleting my master password before updating. After the update, I re-enabled the password. If you already updated and get this crash, you could perform the following steps: - rename and backup localstore.rdf - start SeaMonkey and delete your master password - exit SeaMonkey - delete xulstore.json - restore localstore.rdf - start SeaMonkey and re-enable your master password This worked for me on a broken installation.
Still haven't figured it out fully, but... A newly created 2.30 prefs.js, then opened for the first time, with 2.31 will crash. prefs.js pluginreg.dat xulstore.json all play a roll. Maybe not pluginreg.dat, per se? So... prefs.js xulstore.json It is the combination of a < 2.31 prefs.js & the lack of existence of xulstore.json. Once the Profile has been opened with 2.31, pref.js changes. Some Prefs added, some modified. Once modified, the existence of xulstore.json (&/or pluginreg.dat) becomes immaterial. That said, the existence of xulstore.json becomes an inhibitor to the crash, when used with a < 2.31 prefs.js. prefs.js from 2.30 cat > xulstore.json ^Z Open in 2.31 now works. What is in xulstore.json, be it nothing (0 bytes) or anything at all, "abc123", doesn't matter, just that it exists. Remember that any Profile where xulstore.json does not exist is subject to hit this bug.
Note also reports of /repeated/ crashes on attempting to start up, possibly tied in with the use of a Master Password (& also mentioned by H. Hofer, above)? Bug 1108292 - Repeatedly crashes after updating from 2.30 to 2.31 in Linux i686 & also, http://forums.mozillazine.org/viewtopic.php?p=13915943#p13915943 For me, in all cases, it was a single crash on startup. (I don't use master passwords.)
And you thought we were done! extensions/* also plays a role. In a "clean" (open once & quit) 2.30 Profile, there exists: \extensions\{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi \extensions\inspector@mozilla.org.xpi If you remove BOTH of them, you can then open 2.31 without a crash. If EITHER are left, you will crash. If you rename the extensions to "abc.xpi" & "dumy.xpi", no crash. Oddly... > ren {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi dumy.{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi.dumy > ren inspector@mozilla.org.xpi dumy.inspector@mozilla.org.xpi.dumy Now open 2.31. No crash, but the file dumy.inspector@mozilla.org.xpi.dumy has been DELETED? (Note that you need to start with a "clean" 2.30 in each case cause otherwise other changes factor in.)
> /repeated/ crashes on start up, tied to the use of a Master Password Confirmed.
The xulstore.json I can believe, because when that's not there but localstore.rdf is then there's a one-time migration and that might hit that code path. Anyone got a crash report or stack trace?
(In reply to neil@parkwaycc.co.uk from comment #21) > Anyone got a crash report or stack trace? Here is my crashes reports right after upgrading from 2.30 to 2.31: https://crash-stats.mozilla.com/report/index/c6de1b08-f55d-4449-943e-5b0f22141211 https://crash-stats.mozilla.com/report/index/d7f15c9a-9528-4d08-949c-86c912141211
How is this fixed in Windows Vista 32-bit? There are two profile directories, one in Local, the other in Roaming. I placed xulstore.json in both directories, using a text editor (Wordpad). SeaMonkey still crashes at startup.
Placing xulstore.json in the Windows 7 64-bit profile directory, also did not fix this problem.
(In reply to Edward from comment #30) > Placing xulstore.json in the Windows 7 64-bit profile directory, also did > not fix this problem. It isn't fixed and neither is just putting xulstore.json in the profile directory going to help as it needs some prefs.js changes as well, amongst other things.
Attached file localstore.rdf —
localstore.rdf that crashes
(In reply to Edmund Wong from comment #32) > localstore.rdf that crashes Something else must be the problem; I created a profile, copied this file into it and it was migrated successfully.
(In reply to neil@parkwaycc.co.uk from comment #33) > (In reply to Edmund Wong from comment #32) > > localstore.rdf that crashes > > Something else must be the problem; I created a profile, copied this file > into it and it was migrated successfully. Right. I've been trying to track down this and it's difficult since I only know a smattering of C++. I've been tracing the source and all I'm understanding is that something in panels.rdf is not liked, particularly urn:sidebar:current-panel-list in combination with a missing xulstore.rdf. Right now, after tracing it, I'm up to http://hg.mozilla.org/releases/mozilla-beta/file/987cc98d9229/dom/xul/templates/nsRDFPropertyTestNode.cpp#l213 (Note: this mozilla-beta is not the code that 2.31 is based on. It's 2.33 code, but just pointing out where I am. ) Where sourceRes is defined, but mProperty isn't. So something about the sidebar panel.rdf is screwing up.
Just tried installing released version of 2.32. Same bug is still present. Crash reports submitted automatically at around 13:05 GMT today I have successfully reverted to 2.30
Also having this crash. > Right now, after tracing it, I'm up to > > http://hg.mozilla.org/releases/mozilla-beta/file/987cc98d9229/dom/xul/ > templates/nsRDFPropertyTestNode.cpp#l213 > (Note: this mozilla-beta is not the code that 2.31 is based on. It's 2.33 > code, > but just pointing out where I am. ) > Where sourceRes is defined, but mProperty isn't. In gdb, I could see that the crash happens in the same place as ewong told (nsRDFPropertyTestNode::FilterInstantiations), but because ds is NULL (got from mProcessor->GetDataSource() at the beginning of the function). Both sourceRes and mProperty were set on the run i traced.
Severity: normal → critical
Keywords: crash
I tried installing 2.32.1 and initially got the same problem. It woudl start OK in Safe Mode, but not in normal mode. I removed all Add-ons, bit it still would not start in normal mode. As I had backed up my profile, I tried creating a new profile and restoring the backup from that. This then started successfully in normal mode. I have added back AdBlock Plus, and it is still working with the new profile. 2.32.1 is now runnng happily in normal mode with the new profile.
(In reply to therube from comment #17) > ... > Remember that any Profile where xulstore.json does not exist is subject to > hit this bug. Worked for me! Created empty xulstore.json in profile -> starts in normal mode
Summary: Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ] → startup Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ]
Whiteboard: [startupcrash]
I observed this when updating from SeaMonkey 2.26.1 to 2.33 on each of four profiles. On selecting the Restart SeaMonkey button, SeaMonkey then launched okay. The about:crashes file has ID a53df760-07f6-49c2-a6f5-059982150311.
So what can be done about this? Creating xulstore.json automatically when loading a profile? I am repeatedly encountering this bug on multiple machines, multiple accounts...
For what Target Milestone has this been fixed?
(In reply to Rainer Bielefeld from comment #44) oops, wrong Bug
I am getting this under Windows 7 Ultimate SP1 (x64) with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 SeaMonkey/2.35. The latest crash report with my primary profile has ID bp-315349b8-68ed-4c38-85f1-b03002150724.
This problem did not occur when updating from the contributed version 2.35 to the official version 2.35. This indicates that the cause is somewhere in a preference or capability that was identical between the contributed and official versions.
Still getting this crash when trying to update from 02.30 to 02.38 on x86_64 Linux. So it's not just 2.31-branch that is affected. Crash reports I produced: bp-0f29f55e-d594-4a67-8d3a-1dbfa2151001 2015-10-01 15:25 bp-2fd5832d-ced3-4cc5-8354-b8c492151001 2015-10-01 15:24 bp-9ee6f4f5-8f89-4a14-9eab-8f3ed2151001 2015-10-01 15:23 bp-3a9ee9f9-7463-4c56-92f0-192612151001 2015-10-01 15:23
Version: SeaMonkey 2.31 Branch → unspecified
bug 1057581 is potentially a duplicate of this one.
Crash Signature: [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) ] [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ] → [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) ] [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ] [@ nsRDFPropertyTestNode::FilterInstantiations ] [@ nsRDFPropertyTestNode::FilterInstantiations …
Version 2.31 due to original report, what matches with "Bug 1057581 - old profile crashes on startup [@ nsRDFPropertyTestNode::FilterInstantiations] "
Version: unspecified → SeaMonkey 2.31 Branch
FYI, bug 1254952 have repeatable steps-to-reproduce for this crash.

The affected rdf code has been replaced. I think we can close this one.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: