Closed Bug 195614 Opened 21 years ago Closed 17 years ago

regxpcom shared library is corrupted

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: pavel1r, Assigned: mostafah)

References

Details

Attachments

(1 file)

WIN-ALERT
27.75 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030301
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030301

When I install calendar on latest mozilla build (2003030108), mozilla crashes on
first restart. When I try to run calendar, the message pops up, suggesting to
exit mozilla and run regxpcom. If I run regxpcom, it crashes too.

Reproducible: Always

Steps to Reproduce:
1. Install calendar on latest mozilla build.
2.
3.

Actual Results:  
Mozilla crashes on first startup and install incomplete.

Expected Results:  
Start mozilla normally and complete calendar install.
I tried with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030302
I Installed a calendar-xpi from my harddisk (2003021416-cal)
After Restart I had an Alert as shown in my attatchment

I tried again and Installed from the download page (same calendar- version),
same result.

2003021416-cal does not work with mozilla 1.4a WIN
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image WIN-ALERT — 
This alert is shown when I try to start calendar witn mozilla 1.4a
calendar will start, but I can not se any of my old entries.
I did not test more calendar functions.
This is exactly the alert I see. When I run regxpcom as suggested, it crashes.
Today It worked for me, I Installed 2003021416-cal for
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030304
without any Problem.
Today I had the Problem again and saw message as #2
DUP of bug 191616  ?
#6
Sorry, I wanted to say
This might be a DUP of bug 134432

*** Bug 197053 has been marked as a duplicate of this bug. ***
I have the same problem installing another package aka multizilla. This is *not*
a calendar problem but an installation problem. There is a workaround of this
bug in 134432 bug.
pavelr: please change Product/component to browser/installation and shortdesc to
regxpcom shared library is corrupted
Blocks: 134432
As you requested
Component: Calendar General → Installer
Product: Calendar → Browser
Summary: Calendar does not install on latest mozilla builds (1.4a) → regxpcom shared library is corrupted
Version: unspecified → Trunk
I have a workaround to the installation and component registration problem, and
I am posting it here at Yves' request in bug #134432 (thanks, Yves):

1. Do a clean install of Mozilla.
2. Install your component (Calendar, Multizilla, Enigmail, etc) via the usual
xpi routine, and close the browser completely (including Quick Launch if enabled).
3. Go to your installation directory of Mozilla and find xpcom.dll. Rename
xpcom.dll (but don't delete or overwrite it) to something like xpcom-new.dll.
4. Add the xpcom.dll from the 20030228 (win32) build (build 2003022814 was the
last win32 build that successfully installed .xpi components for me).
5. Run regxpcom.exe (but NOT Mozilla yet!) either by doubleclicking the
executible or by invoking it in a DOS window.  A DOS window will open, about 3-4
lines of messages will fly by (essentially telling you that the component has
been registered) and then close quickly.
6. Restore the current build's proper xpcom.dll by renaming the xpcom.dll file
(from the 20030228 build) to xpcom-old.dll and renaming xpcom-new.dll (from Step
3 above) back to xpcom.dll. (This is important, since the 20030228 xpcom.dll is
seriously incompatible with builds dated after about 20030308 or so.)
7. Now start Mozilla and your component will be fully functional.

_________* A note regarding 2003031216 win32 builds *___________

Several testers, including myself, have noticed that the 2003031216 build has no
"native" xpcom.dll, but the registration of the .xpi components works fine with
the method described above.  However, I still made sure to rename xpcom.dll back
to xpcom-old.dll, since this particular build seems to run fine without any
xpcom.dll at all!  Don't know why this build has no "native" xpcom.dll. Could be
a fluke of this build, or a programmatic change to Mozilla and how it handles
(and registers) components.

________* End note regarding 2003031216 win32 builds *__________

Hope this helps.
Thank you Rainer. Please note that XPcom shared libraries are just used afak for
installation of XPI packages. Works for me with 20031301 mathml libart svg-GDI I
could install an XPI without any problem.
mike: what's the right component for this? It's clearly not installer.
trying xpinstall
Component: Installer → Installer: XPI Packages
Depends on: 194030
196543 is a dupe of this one.

Please check if this one is not a dupe of 194030
Henrik please: can you verify the dependencies and dupes and change the OS to
all please
Blocks: 198041
13 DLL files are missing using sea installer. I got a crash installing calendar
but with sea installer, i got a spirall collector windows. 
Attaching the bug report # to bug 198041
No longer blocks: 198041
WFM with latest [2003031710]mozilla-win32-svg-libart-mathml.zip
This build is not concerned by bug #134432 because this build include Calendar.
I should try to uninstall Calendar and reinstall it for the test, 
I could install mozdev's spellchecker multizilla and googlebox without any problem
and bug 198041 is a WFM too.

Peter : what is a debug build ? and wich one ?
Rainer : your workaround does not work. I had to change a chain of dynamic
libraries in both mozilla directory and mozilla\content directory. i finally
gave up and change all DLLs and regxpcom program finally did not crash.
Blocks: 194030
No longer depends on: 194030
I see this with tonight's build (2003031908).  This is very serious to me, I'm
not gonna use newer versions of mozilla if I can't install the calendar easily.
Flags: blocking1.4a?
Flags: blocking1.3?
Ben: see my comment #17 for a workaround. Mathlm builds are free of this bug,
and Calendar is default on these. This is an installer bug.
What is the deal with mathml builds anyway?  Do they include all of the latest
checkins and bugfixes that the non-mathml builds have?
This might have to do with GRE: I'm using Windows nightly -sea installers which
also install a GRE. In my Mozilla directory there is no xpcom.dll at all and I'm
experiencing all the problems mentioned here (Calendar doesn't finish install,
regxpcom.exe crashes, complaining about not finiding xpcom.dll). BUT there is a
xpcom.dll in C:\Program Files\Shared Files\GRE\<Mozilla version identifier>\ and
if I copy this file to the Mozilla directory, regxpcom doesn't crash anymore. I
have yet to find out if this also fixes the Calendar install problem...
Flags: blocking1.4a?
Flags: blocking1.4a-
Flags: blocking1.3?
Flags: blocking1.3-
Problem solved?
I installed Mozilla Calendar 2003032410-cal 
without problems for
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030328(08)
and
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030325
I'm having the same behavior as described in comment 22, except I'm not trying
to install Calendar at all. This crash happens for me just installing the 1.4a
build on WinXP.
Flags: blocking1.4b?
Since we aren't being built by default, we can't be blocking any milestones.
Flags: blocking1.4b? → blocking1.4b-
I think perhaps I don't understand this bug, then. I'm reporting that the
behavior in comment 22 (i.e. crash on startup unless you copy xpcom.dll into the
moz directory) is happening to me on WinXP with the official Mozilla 1.4a
milestone release.

That seems to contradict comment 25.

Should I open a different bug?
I've just had lots of fun with this bug (or something very like it).

A couple of days ago I tried to install calendar and had similar behaviour to
that reported above (crash first time run, warnings on subsequent runs etc). Not
actually needing it and being too lazy to uninstall it I just left in mozilla
and didn't use it. no problem. (The build I was using is a couple of days old,
20030525-ish i think, on WinXP). 
Well today I had a blue screen when closing down mozilla (happens about 1 time
in 100, a separate mozilla/display driver issue I think) and on restarting the
computer mozilla would not run. No error messages, just nothing happened, either
using a desktop shortcut or from the command line. Restarting did not change
anything. 
OK... so I reinstalled the last build I had. This time it crashes at the end of
the install (when it tries to launch mozilla) and every time I try to run it it
crashes. As I'm lazy (I think I mentioned that already) I didn't remove anything
before I tried re-installing the first time, so now I uninstall mozilla
completely, removing directories etc. Still crashes. I download some older
builds and a milestone just in case. Still crashes.

OK, now I'm confused (and a little scared). I (as far I know) have completely
cleansed the system of any mention of mozilla, but something was still affecting
it when I reinstall. 
Looking at the windows crash-catcher thing it says the exception occured in
xpcom.dll. So I searched bugzilla and found this bug. 
Next problem: I regularly install nightly builds but almost never remove the
previous version (I'm lazy and figure if I'm not going to do it, neither is your
average user, so it should be factored into the design process). This means I
had about 8 directories in the GRE folder (which I didn't know about), all
containing their own xpcom.dll. I delete all these. No change - STILL crashes
when I install.
Hmm... I'm really stuck now. "Ack! All my mail is in there!". 
Now I noticed when I searched for xpcom that the copy of Firebird I'd installed
(and barely used) also had its own version of xpcom.dll, as did a version of
phoenix from months ago that I'd forgotten about (That's about 10 copies of
xpcom.dll for them that's counting). There's a windows command that tells you
which version of a dll is registered, but I couldn't remember what it was so
as a last resort I deleted these two folders and voila! it works! Finally.

From this I deduce several things:
1) Mozilla needs to manage its components better. My Mozilla seems to have been
using a copy of xpcom (or whatever) that was in the Firebird directory. Bad.
2) Mozilla needs to manage new version installations better. Either that or
force an uninstall before a new installation.
2a) I need to manage new version installations better.
3) Mozilla shouldn't allow non-compatible extensions to be installed. (Yes, I
know, not easy)

Now, I focused on xpcom.dll as that seemed to be the root of this bug, but it
could in fact have been anything in those directories. I didn't spend too much
time testing it as I just wanted my mail back. It also could have been nothing
to do within installing calender and what I did just worked by accident but no
previous crash has ever had such severe consequences.

Sorry about the length of this post and the facetiousness of it, but this isn't
ideal behaviour, even under my odd set of circumstances. 

*** Bug 197363 has been marked as a duplicate of this bug. ***
New contact from mikep@oeone.com to mostafah@oeone.com
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.
Assignee: mikep → mostafah
Product: Browser → Seamonkey
both dependent bugs are closed and no activity here, so closing WFM.
Feel free to reopen if you believe this problem is not gone.
Status: NEW → RESOLVED
Closed: 17 years ago
QA Contact: gurganbl → xpi-packages
Resolution: --- → WORKSFORME
Component: Installer: XPI Packages → Installer
QA Contact: xpi-packages → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: