Closed Bug 299411 Opened 19 years ago Closed 19 years ago

Firefox Fails to start, quits silently after profile manager

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: polidobj, Unassigned)

Details

(Keywords: qawanted)

Attachments

(3 files)

DepWalker File
722.97 KB, application/octet-stream
Details
Beast Zip file listing
24.24 KB, text/html
Details
Pacifica zip file listing
13.67 KB, text/html
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.23  [en]
Build Identifier: 

Beast builds fail to start.  According to Mozillazine build forum this started 
late June 30th.  If the profile manager is invoked it will appear but the 
process dies after that.

Filing in SVG because as far as I can tell DepWalker indicates the process dies 
after loading GKSVGGDIPLUS.DLL.

See build threads:
June 1st: http://forums.mozillazine.org/viewtopic.php?t=286291
June 2nd: http://forums.mozillazine.org/viewtopic.php?t=286715

Reproducible: Always
Because it's over 700kbs I can't attach the DepWalker file.  So I put it here:
http://www.lostagain.net/firefox/FIREFOX.zip
URL: http://www.lostagain.net/firefox/FIRE...
This appears to be caused by installing over the exsisting installation.
(from comments on 
http://forums.mozillazine.org/viewtopic.php?t=286644 )

DPA1 Installer -> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050701 Firefox/1.0+ ID:2005070114 (Pacifica build) Installer with an
existing profile does not exhibit this problem.
Severity: blocker → critical
Keywords: qawanted
Maybe I should have noted that this is with a zip build for me.  And I always
extract them to a new directory.  The only installter I have run was 1.0 which
is in another location.  And this build has been tried with existing trunk
profiles and a new profile beings the profile manager is usable.
Attachment #187990 - Attachment is patch: false
Attachment #187990 - Attachment mime type: text/plain → application/octet-stream
The timing of the build breakge seems to coincide with the checkin for bug:
Bug 296626
Firefox trunk 02/07/05 16:48 build, pacifica. Win XP SP2.
Zip build extracted to a fresh directory. Using existing profile.

Does not start, fails silently after the profile dialogue. Firefox process
disapears from the Task Manager.

Steps to reproduce: Download build, try to start

Pacifica Tinderbox is green

http://forums.mozillazine.org/viewtopic.php?t=286644
http://forums.mozillazine.org/viewtopic.php?t=286715
http://forums.mozillazine.org/viewtopic.php?t=286291

contain at least a dozen simular reports.
Assignee: general → nobody
URL: http://www.lostagain.net/firefox/FIRE...
Severity: critical → blocker
Status: UNCONFIRMED → NEW
Component: SVG → General
Ever confirmed: true
Product: Core → Firefox
QA Contact: ian → general
Summary: Beast builds fail to start → Firefox Fails to start, quits silently after profile manager
A new profile and safe mode exhibit the same problem with the 02/07/05 16:48
pacifica build.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701
Firefox/1.0+ ID:2005070105 is working fine for me

> This appears to be caused by installing over the existing installation.
This now appears to have been an incorrect assumption

I don't think comment 5 is significant

Based on the number of comments in the forums requesting blocking 1.8b3 incase
this is a significant recent regression.

Can some careful QA be done to check if this is an unfortunate issue for the few
people that have mentioned it or something likely to be more widespread in the
DPA2 release.
Flags: blocking1.8b3?
Re: Pacifica installer.exe builds downloaded from osuosl mirror, always with an
existing DPA1 profile and multiple extensions, always into empty default DPA1
directory, custom installs with QFA and DOMI checked.  

No problems with hourly downloaded late on 30 Jun. 

First had the problem with hourly downloaded early this afternoon (1 Jul CDT). 

Went back to this nightly, and no problems:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701
Firefox/1.0+ ID:2005070106

Hope this helps with confirming regression timeframe.
See bug 299449, although that regression only could have started 2005-07-01
16:58. Marking blocking+ until the circumstances and steps to reproduce are
clarified.
Flags: blocking1.8b3? → blocking1.8b3+
1) Download LATEST beast .zip build
2) Delete existing FF files / directory or extract to a new directory (for me
it's C:\Program Files\Firefox)
3) Delete or rename existing FF profile
4) Launch FF
5) FF should not launch BUT will have created a new profile silently 
6) Launch Task Manager and notice that FF is NOT running
7) Scream, yell and pull your hair out ;-)
WFM now with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050702 Firefox/1.0+ ID:2005070209 (installer.exe), which contains fix
for bug 299449 (File res/hiddenWindow.html missing in installer build).
New profile, clean install..

WFM with the latest installer build.
Fails to start with latest zip builds (both Pacifica and Beast)
Only Beast zip doesn't startup yet.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702
Firefox/1.0+ ID:2005070213
Probably irrelevant and unimportant, but when I unzip these beast builds, I
always get this message, although I'm using a new clean folder:
http://img142.imageshack.us/img142/8328/confirm0hy.jpg
This is WFM for pacifica builds after the patch for bug 299449 landed.

Brian, Bryan, Tablet, Ria is this still a problem with a build containg the
patch for bug 299449?
FWIW the beast zip build does not start for me.

Comment 15 is due to the fact that the beast zip build packages README.txt and
readme.txt.

Latests Beast zip build 6,631 KiB
Latest Pacifica zip build 6,448 KiB

I am doubtful that the branding differences account for the 183 KiB size difference.

Beast zip contains these files which are not in pacifica zip:
mozctl.dll
mozctlx.dll
README.ycy
\chrome\reporter.jar
\chrome\chromelist.txt
\chrome\reporter.manifest

148 files in \components compared with 24 in the pacifica zip (!)
2 extra files in \res

Its hard to tell what is incorrect due to the branding differences.
If this problem can nolonger be reproduced with pacifica builds then beast
builds should probably be removed from the ftp as a temporary solution.
(In reply to comment #16)
> Brian, Bryan, Tablet, Ria is this still a problem with a build containg the
> patch for bug 299449?

This is WFM using the following PACIFICA build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702
Firefox/1.0+ ID:2005070217

BEAST builds however continue FAILING to start!


beast's builds weren't being maintained since pacifica took over.  This is not a
blocking bug if what pacifica produces is usable.

The real fix is to shutdown beast's hourly build upload, something I should have
done a month ago but never followed through on.  This has been done.

->WONTFIX
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking1.8b3+ → blocking1.8b3-
Resolution: --- → WONTFIX
This is also broken for me.  Tried today's nightly build as well as the latest
Pacifica and they both fail to start for me.  Reverted back to what I was
previously using, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050628 Firefox/1.0+, without any problems.  This is not related to Beast
vs. Pacifica builds, IMO.
I just grabbed this:
firefox-1.0+.en-US.win32.installer.exe 4711 KB 7/3/2005 10:47:00 PM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050703
Firefox/1.0+

WFM so verifying (i guess, i still think this should be WFM because it works
now, or fixed since beast doesn't upload anymore)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: