Closed Bug 234804 Opened 20 years ago Closed 20 years ago

20040218 win32 install won't startup/20040219 crashes/will not start

Categories

(SeaMonkey :: Installer, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: lohphat, Assigned: mscott)

References

Details

(Keywords: qawanted, regression)

Attachments

(1 file)

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040217

Installed the 20040218 nightly and it would not startup, in addidition, IE stole
the default browser status back.

Reproducible: Always
Steps to Reproduce:
1. d/l nightly
2. Install
3. No error (or app) on starting Mozilla

Actual Results:  
Nada

Expected Results:  
Started normally
Yes, yes. I know. This is me trying to get talkback symbol processing working again.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: general → leaf
Status: ASSIGNED → NEW
Three cheers for leaf.
Keywords: qawanted
*** Bug 234815 has been marked as a duplicate of this bug. ***
I just wanted to file a new bug. :-) Installer build 2004021810 WinNT4 has still
the problem. Nothing happens, no error, no zombie process.
I've started my build with NSPR_LOG_MODULES=ALL:5 and got only these 3 lines:

0[781e70]: Loaded library Executable (init)
0[781e70]: Loaded library ws2_32.dll (load lib)
0[781e70]: Unloaded library ws2_32.dll
Same result on WindowsME with 2004021810. 

Asking for blocking1.7a flag. And Matti please don't tell me we are still a
zillion milliseconds from the release, so the flag is not needed.
Flags: blocking1.7a?
A 2004021809 CVS build I luckily made at the same time as the first bad nightly
made did not have this problem. 

I do agreee that the installer is the obvious suspect.
Build 2004021810 still has the problem.
20040219xx win32 now at least crashes with an XP error reporting dialog.  Still
busted.
Yep, but now the installer crashes, not the browser.
The offending modules are setup.exe and xpinstall.dll
build 2004021900, win32.
Win XP SP1, Athlon XP 1800+, 512 MB RAM.
bye!
Why this bug is not "BLOCKER"?
*** Bug 234883 has been marked as a duplicate of this bug. ***
After some speak with Neil and bsmedberg on irc.

The problem is with xpcom.dll.
Mozilla tries to find it in PATH_WHERE_MOZILLA.EXE_IS and not in
'x:\Windows\Shared Files\GRE'

It may be that the bug is caused by the build system.

The mozilla in trunk-2004-02-18-11 installs a GRE with 2004-02-18-10 as version
(as seen in registry) and mozilla self as 2004-02-18-08 ... don't know if this
is related, as I don't know how every mozilla searches for his own GRE.
The GRE registry entries else seems ok for me they look likes the entries from
2004-02-17-09 with different number in version and path (as exspected).
*** Bug 234924 has been marked as a duplicate of this bug. ***
*** Bug 234938 has been marked as a duplicate of this bug. ***
Tweaked summary, bumped up severity, wondered if bug 234976 has same cause as
this one, and pulled for Leaf to get talkback working again.
Severity: normal → critical
Summary: 20040218 win32 install won't startup → 20040218 win32 install won't startup/20040219 crashes
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219
BuildID 2004021913 
http://ftp.mozilla.org/pub/mozilla.org/mozilla/tinderbox-builds/CREATURE/mozilla-win32-installer.exe
gave wrong link in comment #17
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219

BuildID 2004021913 is of course from:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-19-14-1.7a/mozilla-win32-installer.exe
(In reply to comment #17)
> BuildID 2004021913 

Yeah, wfm on WinNT4.
WFM up to this last rel: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7a) Gecko/2004021709

Anything newer fails (on Win2k) with the setup.exe failure.
Bug http://bugzilla.mozilla.org/show_bug.cgi?id=235003 may be a dup?
*** Bug 235003 has been marked as a duplicate of this bug. ***
Blocks: 234976
opi: if the GRE and the app are using different registry keys, that would
definitely cause problems. And we should figure out a better way to report
errors from the XPCOM glue startup, the silent failures are awful.
*** Bug 235095 has been marked as a duplicate of this bug. ***
We got a lot of dupes on this one because the original subject words didn't turn
up in the more obvious search words some of us chose. It would be great if
Bugzilla could be enhanced and extended to provide decision trees of possible
categories and subcategories of the most commone kinds of problems, like some
knowledge bases do. Perhaps they could suggest subject keywords for further
editing by the submitter, to guide the ways subjects are formulated. Who
develops and maintains Bugzilla itself?
*** Bug 235127 has been marked as a duplicate of this bug. ***
*** Bug 235155 has been marked as a duplicate of this bug. ***
Tweaking summary.
Keywords: regression
Summary: 20040218 win32 install won't startup/20040219 crashes → 20040218 win32 install won't startup/20040219 crashes/will not start
*** Bug 235193 has been marked as a duplicate of this bug. ***
*** Bug 235249 has been marked as a duplicate of this bug. ***
*** Bug 235256 has been marked as a duplicate of this bug. ***
*** Bug 235172 has been marked as a duplicate of this bug. ***
would also be nice if the defective build was pulled from the nightlies
directory http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/
Flags: blocking1.7a? → blocking1.7a-
Installed V1.6 production release and all installed and started working again.

Maybe obvious solution to all but me but, I went back to firefox for a day
until I tried it.

Didn't know it was build related.
Now the page itself is blocked, as in "not found."  Probably that should have
been done as soon as it was discovered that the build was a problem, or at least
the build should have been removed with a warning note as to why.
*** Bug 235407 has been marked as a duplicate of this bug. ***
Well, actually, no, the page is working fine.
But still the 19/02 build is there...
I downloaded the 02.24 version, and still had problems.  I get a single page of
coding, and the browser still does not work.  On top of that, I downloaded and
installed ver 1.6, but have lost all of my mail from the previous version, and
have to figure how to get it into my 1.6 profile, until the nightly build is
working correctly.
(In reply to comment #37)
> I downloaded the 02.24 version, and still had problems.  I get a single page of
> coding, and the browser still does not work.  On top of that, I downloaded and
> installed ver 1.6, but have lost all of my mail from the previous version, and
> have to figure how to get it into my 1.6 profile, until the nightly build is
> working correctly.

What version of windows? What other mozilla installations do you have?
Status: NEW → ASSIGNED
Here's what I see in the debugger:

For the deflenus package (US English Profile Defaults), the installation path
string used by all the other previous xpi files that get installed gets
corrupted.   For all the other XPIs, the installation path is something like:

c:\Program Files\Mozilla.org\foo

When this package now gets installed, the SoftwareUpdater has a different
directory path:

c:/Program Files/Mozilla.org/foo

Note the UNIX style directory separators. the nsIFile object that now represents
this path has difficulties because it can't find folders that it expects because
of the wrong separators and we eventually crash because a folder ptr is NULL.

The question is, why are we seeing UNIX style folder delimiters for the deflenus
package and not the others?

Aren't the builds from the 18th the first round of builds with the string API
changes? I wonder if something broke there (just guessing)
this was caused by the string API changes.

We end up modifying a buffer we shouldn't be because a buffer is getting shared
between a nsIFile and a nsCAutoString..

patch coming up. 
Attached patch the fixSplinter Review
Assignee: leaf → mscott
Comment on attachment 142282 [details] [diff] [review]
the fix

In the future, this bug really should have been marked as a blocker and the
tree kept close until it was fixed. Not being able to install the app is pretty
severe :)
Attachment #142282 - Flags: superreview?(dbaron)
Attachment #142282 - Flags: review?(darin)
Severity: critical → blocker
Comment on attachment 142282 [details] [diff] [review]
the fix

r+sr=darin

apparently, i did not do a good enough job searching for these invalid casts :(
Attachment #142282 - Flags: superreview?(dbaron)
Attachment #142282 - Flags: superreview+
Attachment #142282 - Flags: review?(darin)
Attachment #142282 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
(In reply to comment #39)
> Here's what I see in the debugger:
> 
> For the deflenus package (US English Profile Defaults), the installation path
> string used by all the other previous xpi files that get installed gets
> corrupted.   For all the other XPIs, the installation path is something like:
> 
> c:\Program Files\Mozilla.org\foo
> 
> When this package now gets installed, the SoftwareUpdater has a different
> directory path:
> 
> c:/Program Files/Mozilla.org/foo
> 
> Note the UNIX style directory separators. the nsIFile object that now represents
> this path has difficulties because it can't find folders that it expects because
> of the wrong separators and we eventually crash because a folder ptr is NULL.
> 
> The question is, why are we seeing UNIX style folder delimiters for the deflenus
> package and not the others?
> 
> Aren't the builds from the 18th the first round of builds with the string API
> changes? I wonder if something broke there (just guessing)


(In reply to comment #38)
> (In reply to comment #37)
> > I downloaded the 02.24 version, and still had problems.  I get a single page of
> > coding, and the browser still does not work.  On top of that, I downloaded and
> > installed ver 1.6, but have lost all of my mail from the previous version, and
> > have to figure how to get it into my 1.6 profile, until the nightly build is
> > working correctly.
> 
> What version of windows? What other mozilla installations do you have?

I have Windows 2000 Professional.  I had no other mozilla installations at all.
 Presently, I have 1.6, after having deleted mozilla nightly build.  I've only
ever had mozilla nightly build on my computer, and that is all.  But that one
page of coding was weird - it was a yellow page, no navigation buttons, etc.,
just coding that ran down below the bottom of the screen.  But, of course, it is
gone now that I installed 1.6 over it.
*** Bug 235655 has been marked as a duplicate of this bug. ***
The weird yellow page reminded me.
When I first installed the build over the previous (7-10 day old) nightly I was
running, I accepted the totally blank license agreement it presented.
On subsequent atttempts, the license agreement was visible.
Why is this marked as FIXED? It still crashes (Gecko/2004022509 Windows XP).

-> REOPEN
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Because you have an old build. Please compare the checkin date and the date of
your build before you reopen a bug.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
It was the latest I could find
(<http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/>), I will
wait an extra day.
*** Bug 235682 has been marked as a duplicate of this bug. ***
*** Bug 235734 has been marked as a duplicate of this bug. ***
*** Bug 235684 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Finally!!!!
Just dloaded mozilla build 2004022608 and it works!!!!
Well done, guys!
bye!
WFM too, but after the install it asked me if I wanted to set Moz as the default
browzer and MAPI client.  How did they get reset? I installed from a pre-broken
install.
Product: Browser → Seamonkey
*** Bug 235662 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.