Firefox 0.9 crashes on startup due to enabled software/auto update - FF09 [@ msvcrt.dll - dosprintf]

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
15 years ago
11 years ago

People

(Reporter: markushuebner, Assigned: bugs)

Tracking

({crash, regression, topcrash})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Workaround: See comment 16, crash signature, )

Attachments

(1 attachment)

Reporter

Description

15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
Build Identifier: Official 0.9 release

When starting the official release of Firefox 0.9 it crashes on startup - 
everytime.

Here are some TB reports:
TB116707G
TB116699E
TB116625Q


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Reporter

Updated

15 years ago
Keywords: crash
Reporter

Comment 1

15 years ago
This crash happens on several computers in our company having Firefox 0.9 
installed (over 0.8 as well as completely new (firefox for the first time)).

The very strange this is that FireFox worked fine for 2 days but suddenly 
today crashes on the computers on startup - with no other software / patches 
installed.

I think the analysis of the TB reports will bring more light here.

Comment 2

15 years ago
Had the same problem this morning, my 0.9 was working fine and then it crashed. 
There are several bug reports on this issue though.
Reporter

Comment 3

15 years ago
Wow - is there a time-counter crasher?! ;)
Summary: Firefox crashes on startup (everytime) → Firefox 0.9 crashes on startup (everytime)
Reporter

Comment 4

15 years ago
This problem seems to be very visible to other users too 
http://forums.mozillazine.org/viewtopic.php?t=86074
Reporter

Comment 5

15 years ago
In the forum a user reported the commenting out the last line of prefs.js like
/* 
* user_pref("update.lastUpdateDate", 1375609856); 
*/
fixes the problem.

So this seems to be a preference / profile problem?

Comment 6

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

Comment 7

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

Comment 8

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

Updated

15 years ago
Flags: blocking1.0?

Comment 9

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

Updated

15 years ago
Whiteboard: Workaround: See comment 5

Comment 10

15 years ago
I have Windows XP with Firefox 0.9 installed. It also crashes on startup. I 
looked for prefs.js and could find no such file. There are two files called 
security-prefs.js but neither has the line 'user_pref("update.lastUpdateDate", 
1375609856);'. 

I looked through some of the other .js files and still could not find 'user_pref
("update.lastUpdateDate", 1375609856);'

(In reply to comment #5)
> In the forum a user reported the commenting out the last line of prefs.js like
> /* 
> * user_pref("update.lastUpdateDate", 1375609856); 
> */
> fixes the problem.
> So this seems to be a preference / profile problem?

Comment 11

15 years ago
I had this happen yesterday.  I did uninstall the RC before installing 0.9
final.    Just started crashing on startup for no reason at all. I had NO
extensions installed.  I could start the profile manager.  Someone mentioned
that deleting prefs.js fixes this but I solved it by uninstalling FF, deleting
my profile, and reinstalling.  Needless to say this needs to be fixed NOW.  A
new user who encounters this will uninstall FF and never look back. . .  IMHO,
this bug alone should justify a creation of a 0.9.1 release.

Comment 12

15 years ago
I found the prefs.js file in Comment #5 but could not find the appropriate line 
so I followed the advice in Comment #11 and delted all profiles and reinstalled 
0.9.

It works fine now but we'll see what happens tomorrow.

One additional note, the first time I had 0.9 installed (just before this whole 
crashing incident) I imported my IE bookmarks, which I did not do this time 
around. I don't know if this will make a difference or not. I'm keeping my 
fingers crossed.

(In reply to comment #11)
> I had this happen yesterday.  I did uninstall the RC before installing 0.9
> final.    Just started crashing on startup for no reason at all. I had NO
> extensions installed.  I could start the profile manager.  Someone mentioned
> that deleting prefs.js fixes this but I solved it by uninstalling FF, deleting
> my profile, and reinstalling.  Needless to say this needs to be fixed NOW.  A
> new user who encounters this will uninstall FF and never look back. . .  IMHO,
> this bug alone should justify a creation of a 0.9.1 release.

Comment 13

15 years ago
I had the same problems - 0.9 working at first and then crashing on startup the
next day - and I searched through the prefs.js file and also found that the line
"user_pref("update.lastUpdateDate", 1375609856);" caused the crash. When I
commented it out, everything worked.

Updated

15 years ago
Keywords: regression

Comment 14

15 years ago
This bug showed up for me yesterday. I got around it by changing the shortcut to
have "-p" after it, then I made a new profile and deleted my old one. It has
been running okay since, but I suppose it is possible it's only a matter of time
before it happens again.

There doesn't seem to be a fix relating to installation of the product, since it
seems to be a profile issue.

I had uninstalled 0.8 and deleted the Mozilla folder in Program Files before I
installed 0.9. Approximately 20 hours later, after a PC reboot, Firefox 0.9 just
stopped working. It would crash everytime on startup. Usually it would show the
title bar, but sometimes that wouldn't even appear.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

Comment 15

15 years ago
I experienced the exact same problem.  I did a clean install of Mozilla Firefox 
0.9, and the next day I started experiencing these crashes on start-up.  The 
only way I was able to get around it was to delete my profile and create a new 
one.  This was on a Windows 2000 Professional machine.

From the comments on MozillaZine forums, it appears to be somehow related to 
Software Update and the profile.  One theory is that this bug can be worked 
around if all software update options are disabled.

Comment 16

15 years ago
If Firefox is set as the default browser in WinXP, right-click the Firefox item
in the Start menu->Firefox options->Advanced->Disable auto-update. 

That should work around the problem.

Comment 17

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

Updated

15 years ago
Summary: Firefox 0.9 crashes on startup (everytime) → Firefox 0.9 crashes on startup due to enabled software/auto update
Whiteboard: Workaround: See comment 5 → Workaround: See comment 16

Comment 18

15 years ago
I have the same problem where it crashes in msvcrt.dll @0x0003381c on startup.
However, when started under Visual Studio .NET 2003, the problem does not occur
and firefox runs fine. Also, starting a second instance outside of VS.NET also
works. However, the first instance always fails if started outside of VS.NET.

Attempting to use the JIT debugger on the failing instance does not produce a
usable call stack to assist the diagnosis.

Comment 19

15 years ago
same bug here, different fix.
I noticed that it seems to crash only for me if I changed my homepage to
about:blank. It seems to crash after awhile of using this setting. Once it
starts crashing, I can fix it either by using clean profile, OR by setting the
default page in prefs.js to something other than the blank page I normally like.
I see the problem too, on two of my machines, both WinXP and Win2003 Server. 
Only a complete reinstall, including new profile, fixed it--though probably that
is because it overwrote the prefs.  It did not start crashing until the day
after I installed it.

bug 247252 and bug 247273 are probably this same crash, and bug 247314 *might*
be, not enough info yet.

Comment 21

15 years ago
-> Software Update.

The was probably caused by http://update.mozilla.org/update.rdf being an empty
file for some time, see bug 247362 comment 8. Firefox queries this file for
software updates (like Firefox 1.0 later on). The url to this file is specified
in the pref "update.app.url".

I can reproduce the crash by pointing the url to my own server, providing an
empty update.rdf, served as text/rdf, an then starting Software Update.
Assignee: firefox → bugs
Component: General → Software Update
QA Contact: firefox.general → bugs

Comment 22

15 years ago
i was guessing some similar reason in my bugreport, but it has been quickly
marked as duplicate

http://bugzilla.mozilla.org/show_bug.cgi?id=247398

there i tried to give some hints what might have been wrong, not knowing the
software update machanisms of firefox at all, but it was obvious to me that it
had something to do with the retrieving and then handling of the software update
status.

---

...so i guess that currently there is something wrong eiterh with the firefox
software update code, with the software update mechanisms, like the urls,
servers or scripts or something like that....

Comment 23

15 years ago
Weird, I can't reproduce this anymore with an empty file. But
http://update.mozilla.org/update.rdf has been removed anyway. Bug 247362 is
about uploading a proper file.
*** Bug 247273 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: topcrash
Summary: Firefox 0.9 crashes on startup due to enabled software/auto update → Firefox 0.9 crashes on startup due to enabled software/auto update - FF09 [@ msvcrt.dll - dosprintf]

Comment 26

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

Comment 27

15 years ago
Is anyone still experiencing this bug?

Comment 28

15 years ago
Presumably not, seeing as it's been fixed at the UMO site. Needs a testcase
elsewhere really, to establish if the browser needs fixing. Although it's of
lesser importance, it should still be fixed in the code if the problem still
exists...
Flags: blocking1.0?

Comment 29

15 years ago
(In reply to comment #28)
> Presumably not, seeing as it's been fixed at the UMO site. Needs a testcase
> elsewhere really, to establish if the browser needs fixing. Although it's of
> lesser importance, it should still be fixed in the code if the problem still
> exists...

Agreed, the browser should be robust enough to not crash regardless of what's
happening at the update site.

Comment 30

15 years ago
Is this fixed with the patch for bug 248071?  

They have a similar stack and the patch for bug 248071 puts a check in EndLoad
to ensure this won't crash:

Talkback trace:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB116699E
Patch for bug 248071:
http://bugzilla.mozilla.org/attachment.cgi?id=151566&action=view

Comment 31

15 years ago
Posted file Empty rdf file
Blank .rdf file for testing

Comment 32

15 years ago
Steffen Wilberg: If you change your update URL to:

http://bugzilla.mozilla.org/attachment.cgi?id=151704&action=view

in Firefox 0.9, does it still crash?  

Comment 33

15 years ago
No, it doesn't crash (as I've said in comment 23 already).
I used my 0.9.1 build from today.
I created a new profile and made these settings in about:config:
javascript.options.showInConsole = true
javascript.options.strict = true
update.app.url = http://bugzilla.mozilla.org/attachment.cgi?id=151704&action=view

I doubleclicked the software update area of the status bar. The update dialog
popped up, but nothing happens.
The js console shows (besides a bunch of strict warnings) this error:

Error: aDS.GetTarget(app, this._ncR(aProperty), true) has no properties
Source File: file:///D:/Internet/Firefox/components/nsBackgroundUpdateService.js
Line: 190

context is this:
_getProperty: function (aDS, aAppID, aProperty)
  {
    var app = this._rdf.GetResource("urn:mozilla:app:" + aAppID);
    return aDS.GetTarget(app, this._ncR(aProperty),
true).QueryInterface(Components.interfaces.nsIRDFLiteral).Value;
  },

I have to click the close icon in the top right corner to get rid of the dialog.

The hang of the dialog only happens when pointing "update.app.url" to an empty
rdf file. It works fine with the default setting (u.m.o/update.rdf). But again,
I can't reproduce a crash anymore since comment 23.
The hanging dialog should be fixed of course.

Updated

15 years ago
Flags: blocking1.0?

Comment 34

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

Comment 35

15 years ago
*** Bug 248187 has been marked as a duplicate of this bug. ***
The crash should be fixed, file other bugs separately. 
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Flags: blocking-aviary1.0?

Comment 37

15 years ago
Just got it using version 1.0PR.

Also had it happening with a trunk build which is a week old now, bug should 
be re-opened.
Product: Firefox → Toolkit
Crash Signature: [@ msvcrt.dll - dosprintf]
You need to log in before you can comment on or make changes to this bug.