195614 - regxpcom shared library is corrupted

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect)

Description

[Pavel]

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.

Comment 1

[Rainer Bielefeld]

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

Comment 2

[Rainer Bielefeld]

Attachment: 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.

Comment 3

[Pavel]

This is exactly the alert I see. When I run regxpcom as suggested, it crashes.

Comment 4

[Rainer Bielefeld]

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.

Comment 5

[Rainer Bielefeld]

Today I had the Problem again and saw message as #2

Comment 6

[Rainer Bielefeld]

DUP of bug 191616  ?

Comment 7

[Rainer Bielefeld]

#6
Sorry, I wanted to say
This might be a DUP of bug 134432

Comment 8

[Yves Lambert]

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

Comment 9

[Yves Lambert]

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

Comment 10

[Pavel]

As you requested

Comment 11

[Daniel Kies]

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.

Comment 12

[Yves Lambert]

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.

Comment 13

[Henrik Gemal]

mike: what's the right component for this? It's clearly not installer.
trying xpinstall

Comment 14

[Yves Lambert]

196543 is a dupe of this one.

Please check if this one is not a dupe of 194030

Comment 15

[Yves Lambert]

Henrik please: can you verify the dependencies and dupes and change the OS to
all please

Comment 16

[Yves Lambert]

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

Comment 17

[Yves Lambert]

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 ?

Comment 18

[Yves Lambert]

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.

Comment 19

[Ben Ruppel]

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.

Comment 20

[Yves Lambert]

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.

Comment 21

[Ben Ruppel]

What is the deal with mathml builds anyway?  Do they include all of the latest
checkins and bugfixes that the non-mathml builds have?

Comment 22

[Jens Hatlak (:InvisibleSmiley)]

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

Comment 23

[Rainer Bielefeld]

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

Comment 24

[Ray Trent]

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.

Comment 25

[Mike Potter]

Since we aren't being built by default, we can't be blocking any milestones.

Comment 26

[Ray Trent]

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?

Comment 27

[Nick Lott]

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. 

Comment 28

[Asa Dotzler [:asa]]

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

Comment 29

[Mike Potter]

New contact from [e-mail] to [e-mail]
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.

Comment 30

[Wayne Mery (:wsmwk)]

both dependent bugs are closed and no activity here, so closing WFM.
Feel free to reopen if you believe this problem is not gone.