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

VERIFIED FIXED

Status

--
blocker
VERIFIED FIXED
15 years ago
14 years ago

People

(Reporter: lohphat, Assigned: mscott)

Tracking

({qawanted, regression})

Trunk
x86
Windows XP
qawanted, regression
Bug Flags:
blocking1.7a -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

Updated

15 years ago
Assignee: general → leaf
Status: ASSIGNED → NEW

Comment 2

15 years ago
Three cheers for leaf.
Keywords: qawanted
*** Bug 234815 has been marked as a duplicate of this bug. ***

Comment 4

15 years ago
I just wanted to file a new bug. :-) Installer build 2004021810 WinNT4 has still
the problem. Nothing happens, no error, no zombie process.

Comment 5

15 years ago
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

Comment 6

15 years ago
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?

Comment 7

15 years ago
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.

Comment 8

15 years ago
Build 2004021810 still has the problem.
(Reporter)

Comment 9

15 years ago
20040219xx win32 now at least crashes with an XP error reporting dialog.  Still
busted.

Comment 10

15 years ago
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!

Comment 12

15 years ago
*** Bug 234883 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
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. ***

Comment 15

15 years ago
*** Bug 234938 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
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

Comment 17

15 years ago
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

Comment 18

15 years ago
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

Comment 19

15 years ago
(In reply to comment #17)
> BuildID 2004021913 

Yeah, wfm on WinNT4.

Comment 20

15 years ago
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?

Comment 21

15 years ago
*** Bug 235003 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 234976

Comment 22

15 years ago
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.

Comment 23

15 years ago
*** Bug 235095 has been marked as a duplicate of this bug. ***

Comment 24

15 years ago
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?

Comment 25

15 years ago
*** Bug 235127 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
*** Bug 235155 has been marked as a duplicate of this bug. ***

Comment 27

15 years ago
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. ***

Comment 29

15 years ago
*** Bug 235249 has been marked as a duplicate of this bug. ***

Comment 30

15 years ago
*** Bug 235256 has been marked as a duplicate of this bug. ***

Comment 31

15 years ago
*** 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/

Updated

15 years ago
Flags: blocking1.7a? → blocking1.7a-

Comment 33

15 years ago
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.

Comment 34

15 years ago
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.

Comment 35

15 years ago
*** Bug 235407 has been marked as a duplicate of this bug. ***

Comment 36

15 years ago
Well, actually, no, the page is working fine.
But still the 19/02 build is there...

Comment 37

15 years ago
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
(Assignee)

Comment 39

15 years ago
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)
(Assignee)

Comment 40

15 years ago
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. 
(Assignee)

Comment 41

15 years ago
Posted patch the fixSplinter Review
Assignee: leaf → mscott
(Assignee)

Comment 42

15 years ago
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)
(Assignee)

Updated

15 years ago
Severity: critical → blocker

Comment 43

15 years ago
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+
(Assignee)

Updated

15 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 44

15 years ago
(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.

Comment 45

15 years ago
*** Bug 235655 has been marked as a duplicate of this bug. ***

Comment 46

15 years ago
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.

Comment 47

15 years ago
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
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 49

15 years ago
It was the latest I could find
(<http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/>), I will
wait an extra day.

Comment 50

15 years ago
*** Bug 235682 has been marked as a duplicate of this bug. ***

Comment 51

15 years ago
*** Bug 235734 has been marked as a duplicate of this bug. ***

Comment 52

15 years ago
*** Bug 235684 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Status: RESOLVED → VERIFIED

Comment 53

15 years ago
Finally!!!!
Just dloaded mozilla build 2004022608 and it works!!!!
Well done, guys!
bye!
(Reporter)

Comment 54

15 years ago
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

Comment 55

14 years ago
*** 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.