Closed Bug 234804 Opened 21 years ago Closed 21 years ago

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

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: lohphat, Assigned: mscott)

References

Details

(Keywords: qawanted, regression)

Attachments

(1 file)

the fix
680 bytes, patch
darin.moz
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
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 fix — — Splinter 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: 21 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: 21 years ago → 21 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.

Attachment

General

Creator:
Created:
Updated:
Size: