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)

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

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

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.

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.

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

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

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.

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?

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

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?

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?

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.

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

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.

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.

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

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

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

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

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.)

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.

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

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

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.

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

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

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]