172586 - Installing a trunk build over a branch build leaves old xpt files - which cause many crashes on Trunk [@ nsTreeBodyFrame::IsCellCropped] [@ nsTreeBodyFrame::GetCellAt] [@ nsMsgIncomingServer::Equals] [@ PREF_GetBoolPref] [@ nsPromiseFlatCString::nsProm...

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[timeless]

This is just a placeholder for facts i've gathered while using the stub
installer, we can dupe it against some bug later.

w2k adv svr, terminal services. in a terminal session (on my laptop)
ran mozilla-win32-installer.exe - 213 KB (218,320 bytes) - October 03, 2002,
7:43:06 PM
(ie the latest trunk stub installer)

Comment 1

[timeless]

Attachment: file monitor log

Here's the log, grep for autoreg. We're clearly messing up a bit
(NAME_COLLISION is bad).
but it does look like an .autoreg existed before i ran mozilla

Comment 2

[timeless]

Attachment: file list after installation

oh right, sea used to be a n6/n7 install not a mozilla install

Comment 3

[timeless]

Attachment: compreg.dat

Comment 4

[timeless]

ok, i've crashed a few times and i know who/what to blame

you can see from exibit B - attachment 101702 [details]
that the components dir included 3 interloppers, browser.xpt, mail.xpt and psm.xpt.

Something needs to be sure to either kill them or ignore them.

Having just browser.xpt and running regxpcom results in a broken profile manager.

Comment 5

[Daniel Veditz [:dveditz]]

Is that summary right? It's totally invalid to install Mozilla on top of some
other product (or vice versa). Reasonable to expect product FOO to know how to
handle upgrade installs on top of ITSELF, but not to expect it to know about
variant differences.

Comment 6

[Henrik Gemal]

install Mozilla on top of Netscape is INVALID. So either change subject or move
to INVALID.

Comment 7

[Henrik Gemal]

current subject:
"Stub Installer over n7 doesn't clean up well enough"
is invalid. Dont install N7 over Mozilla!

Comment 8

[timeless]

oh cut it out. the fact is that people have confirmed the presence of these
files. I can't even prove that my sea directory was an n7 install, the only
thing present in it was components, i had deleted the contents of the parent
directory.

what i can say is that mozilla installer picked the directory, which means that
either mozilla's installer is foolishly sharing a path with n7 or i'm wrong
about the assertion that the second party was n7.

Comment 9

[David Bradley]

Bryner discovered this. I verified in talkback as well. These crashes are only
trunk crashes and the trunk builds no longer combine the xpt files.

Bryner:
It looks like several of the trunk topcrashes are being caused by the fact that
we're no longer getting xpt files linked together in nightly builds on Windows.
 This means that if you install a nightly build over, say, Mozilla 1.2a, we have
a bunch of individual .xpt files from the nightly, and stale
browser.xpt/mail.xpt files from the previous install.  This gives us stale
interface information, which causes all sorts of problems.

We think this broke sometime around 9/11-9/13, but there aren't any obvious
checkins that would have affected this.  I do see that you changed the win32
verification build script on 9/16; could that be related?

Comment 10

[Daniel Veditz [:dveditz]]

Why do we no longer combine .xpt files? They were originally combined for
performance reasons... are they split up again for bloat reasons or is it just a
bug that will eventually switch back?

The real solution, should someone have the time to implement it, would be to
combine the used-at-startup individual xpt files (and I mean per-interface, not
the current globbed-by-directory ones) and put all the rest in .zip files using
a mechanism similar to jar.mn

Comment 11

[Brian Ryner (not reading)]

I think a bug was introduced into the windows nightly build script that caused
us to stop linking the xpt files.

So, when we get that fixed, we'll then have the problem that users could have
stale individual .xpt files hanging around.  Should we have the installer delete
those?

Comment 12

[hacker formerly known as [e-mail]]

So how do you determine that a particular .xpt is "stale" as opposed to being a
3rd party addon? Are you just going to automatically remove any .xpts from a
predetermined list?

Comment 13

[timeless]

dbradley and i talked about that for a while this weekend.

it is possible for xpconnect to detect when two files define an interface.
Unfortunately it is impossible for xpconnect to know which xpt file to prefer
:). Datestamps are useless when you have a living branch competing with the
trunk and there's no used version field in the xpt files (we could bump minor by
one to recover from this current debacle but i'm not sure what the consequences
would be, esp for third parties).

The latest/greatest idea we have for the future is to include the xpt data into
the dll's.  In that format it would be ok for two files define an interface, and
if the interfaces didn't match we could let things fail instead of crashing later.

For now, I think that we should teach the xpi's how to clean up this mess (that
means listing lots of xpt files).

For zip files, I think we implement a simple alert for when we detect
conflicting interface definitions which says: "This installation is broken
please reinstall mozilla or delete the contents of your components directory."

Anyone using a zip file is capable of lxr'ing for whatever unique string we put
in the alert, and they can then read the bug to find out how to manually recover
if they feel some aversion to reinstalling.  I think that it would be possible
for zip users to run the installer _once_ after it's been fixed to have it clean
up the components directory, and then they can go back to using zips.

Comment 14

[Brian Ryner (not reading)]

I think we almost have to list all of the affected xpt files explicitly.

Comment 15

[Daniel Veditz [:dveditz]]

We don't want to embed the .xpt info into dlls. What do you do for interfaces
that don't have a binary implementation?

Rather than deleting the extra files from the standard install scripts you could
create a one-off .xpi that does nothing but clean up an old mess. Then tell
people who have the problem (because they don't listen to us when we say never
install a nightly on top of another build) to run the extra cleanup .xpi -- this
would work for people who install zips, too.

Comment 16

[Daniel (Leaf) Nunes]

Attachment: remove all the singleton .xpt files when you install browser.xpi

i'm going to dinner (took me a while to get this list off of a remote windows
machine, and bryner reminded me that the .xpt files are listed in the
manifests).

When i get back from dinner, i'll split out the .xpt cleanup into the several
.jst files for each xpi.

Comment 17

[Brian Ryner (not reading)]

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

Comment 18

[Brian Ryner (not reading)]

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

Comment 19

[Brian Ryner (not reading)]

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

Comment 20

[Brian Ryner (not reading)]

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

Comment 21

[greer]

Leaf, have you implemented the changes from comment #16 already? (The crash
signatures exposed by this issue have stopped showing up as of the 10/8 builds
on the Trunk.)

Comment 22

[Jay Patel [:jay]]

Many topcrash bugs were marked dups of this bug, so I did the following:

Updated summary with all the stack signatures caused by the xpt file issue:
which cause many crashes on Trunk [@ nsTreeBodyFrame::IsCellCropped] [@
nsTreeBodyFrame::GetCellAt] [@ nsMsgIncomingServer::Equals] [@ PREF_GetBoolPref]
[@ nsPromiseFlatCString::nsPromiseFlatCString]  [@ XPCWrappedNative::CallMethod]

Added topcrash+ keyword for future reference and topcrash tracking.

Leaf must have made the changes he said he would b/c I haven't seen any of these
crashes since 10/7 MozillaTrunk builds.   Leaving it up to him to mark this fixed.

Comment 23

[Brian Ryner (not reading)]

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

Comment 24

[Christopher Blizzard (:blizzard)]

Any luck with this?  This is on the 1.2 list.

Comment 25

[Jay Patel [:jay]]

The crashes noted in the summary have all gone away.  I'm pretty sure Leaf made
the necessary changes a while back, so marking this fixed for him.

Comment 26

[timeless]

Attachment: leaf's patch shared across jst's

Comment 27

[Andrew Hagen]

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

Comment 28

[David Bradley]

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

Comment 29

[timeless]

The original summary for this bug was longer than 255 characters, and so it was truncated when Bugzilla was upgraded. The original summary was:

Installing a trunk build over a branch build leaves old xpt files - which cause many crashes on Trunk [@ nsTreeBodyFrame::IsCellCropped] [@ nsTreeBodyFrame::GetCellAt] [@ nsMsgIncomingServer::Equals] [@ PREF_GetBoolPref] [@ nsPromiseFlatCString::nsPromiseFlatCString]  [@ XPCWrappedNative::CallMethod]