Closed Bug 1092810 Opened 10 years ago Closed 1 year 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)

SeaMonkey 2.31 Branch
x86_64
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: stefan_gies, Unassigned)

References

()

Details

(Keywords: crash, Whiteboard: [startupcrash])

Crash Data

Attachments

(6 files)

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: 1 year 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: