6.93 KB, text/plain
This bug I can reproduce only with this version of FF: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 I'm not able to start Firefox with the command line option "-profilemanager". The process is stopped immediately. I also checked it with VMWare under Win98 and I can reproduce it there.
I can confirm that with Windows 2000, but Windows XP works just fine.
Sorry, I have to withdraw my last comment. The Problem is not OS-dependend but depends on whether you use the installer or zip version. So the profilemanager works in the installer, but not in the zip version.
(In reply to comment #2) > Sorry, I have to withdraw my last comment. The Problem is not OS-dependend but > depends on whether you use the installer or zip version. So the profilemanager > works in the installer, but not in the zip version. Right. Today we installed the version 0.9.2 on a fresh system and all works fine. Strange behavior. Could someone byte compare both versions where the differences are?
*** Bug 250913 has been marked as a duplicate of this bug. ***
While creating bug 253513 i noticed that this behavior also occurs for current nightly builds. I havn't time to test the lastest builds to see since which version this appears for 0.9.1+ branch builds. Currently i use Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040728 Firefox/0.9.1+
I also noticed the bug in the 0.9 nightlies. The last 'working' version I have is: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+
OK, I tried several nightlies, and the FIRST 0.9 version that has this error is: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040725 Firefox/0.9.1+ Downloaded from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-07-25-22-0.9/Firefox-win32.zip This appears to be built late on July 25.
Gregor, could you also test a current setup build of FF 0.9+ branch?
Created attachment 154681 [details] Diff between installer (ffinst9) and zip (ffw32now9) I compared the ZIP build vs the Setup build for: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040729 Firefox/0.9.1+ Error exists only in the Setup build.
I meant to say 'only in the ZIP build.' !!
Ben/bryner, this looks like a blocker; I don't see an obvious suspect checkin.
*** Bug 253513 has been marked as a duplicate of this bug. ***
I performed a diff of the existing files for the installer and zip builds. I found that browser.xpt only existed in the installer build, copied it to my components directory for my zip build installation, deleted the compreg.dat file, started firefox.exe with the -ProfileManager switch, and the -ProfileManager switch brought up the profile manager. This was the only file I needed from the installer build to get -ProfileManager to work with the zip build.
I realized my diff logic was flawed since it didn't compare a working against a non-working zip build. It turns out that the zip builds started including compreg.dat sometime after 0.9.1 was released... the 0.9.2 release included it. I installed the following branch zip build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040731 Firefox/0.9.1+ I then verified -ProfileManager didn't work a couple of times. I then deleted the compreg.dat file and -ProfileManager worked consistently.
(In reply to comment #14) > I then verified -ProfileManager didn't work a couple of times. I then deleted > the compreg.dat file and -ProfileManager worked consistently. Same for me. Looking at the size of the file compreg.dat shows following diff: original: 2.857 bytes new created: 136.544 bytes
I haven't removed several previous branch zip builds and believe the following shows some of the inconsistency with the builds regarding compreg.dat compreg.dat not included: 0.9.1, 7/17, 7/19, 7/22, 7/24 compreg.dat included: 0.9.2, 7/26, 7/28, 7/29, 7/31 I realize this is a separate issue but I find it strange that the installer build would include browser.xpt and the zip build does not. Should this be removed from the installer build or added to the zip build? I have come to expect that the installer build contains a subset of the xpt's in the zip build.
If the -ProfileManager switch is used on the first run after removing the compreg.dat file the following error is displayed: Application popup: firefox.exe - Application Error : The instruction at "0x010dafeb" referenced memory at "0x00000005". The memory could not be "written". Talkback does not activate I assume because it is possibly too early in the startup. Firefox will then start successfully after this error even without clicking the ok button. All attempts to use the -ProfileManager switch after this are successful and do not exhibit this error. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.1+
I can't confirm the crash with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.1+ Could it be a WinXP only problem?
1) compreg.dat is *never* supposed to be shipped. I wonder how/why we're shipping it. 2) Maybe the crash is from bryner's patch to compare the datestamp of compreg.dat against the .autoreg file?
(In reply to comment #19) > 1) compreg.dat is *never* supposed to be shipped. I wonder how/why we're > shipping it. It is inconsistently included in the zip build as shown in comment #16 though it has been in the zip builds very consistently as of late and there is also the browser.xpt being part of only the installer build though this is unrelated. > 2) Maybe the crash is from bryner's patch to compare the datestamp of > compreg.dat against the .autoreg file? The .autoreg file is not included in the zip build and if the compreg.dat is not in the zip build I don't believe it is necessary to have the .autoreg file. I did test the zip build with an .autoreg file along with the compreg.dat from the zip build and the components are re-registered though I still get the same error with a clean profile with no extensions. I also tested this repeatedly.
Kicking off the blocking list... we don't officially endorse zip builds.
A lot of people i know use zip builds every day. It's a hassle to delete the compreg.dat every time i unpack a new version. Also when you mean it is not a blocker while zip builds aren't endorsed i hope this will be fixed soon. As the simplest solution this file shouldn't be shipped and could be deleted during the build process. How big is the ratio of downloaded setup and zip-builds of Firefox? You mean zip-builds are not endorsed but i think users who downloaded the builds should be ask. If over 50 percent have downloaded the lastest release as zip-build it should be repaired for future builds. The ratio won't change too much for setup builds that we could leave them alone.
Firefox-win32-0.9.3.zip appears to have a working Profile Manager now. I clicked on RUN and used... "C:\Program Files\Mozilla\firefox\firefox.exe" -P
This bug is resolved by another fix. With todays build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040810 Firefox/0.9.1+ the compreg.dat contains all neccessary data and FF is starting with the profile manager without deleting the compreg.dat manually. Same for current trunk builds. Marking as WFM.