Closed Bug 334616 Opened 18 years ago Closed 18 years ago

Crash just after Starting Firefox [@ ntdll.dll]

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 336593

People

(Reporter: bugmozz, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Possible stack
7.52 KB, text/plain
Details
Assertions
1.22 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1 ID:2006041810 [cairo]

0417 Cairo does not crash.

TB17718628Q
TB17729228G

Reproducible: Sometimes

Steps to Reproduce:
1.run Firefox
2.crashe in several seconds
most likely a dupe of Bug 328428 , but somehow this seems to have regressed further.

Disable Talkback if you don't want to crash (currently trunk is stable enough to do w/o talkback)
(In reply to comment #1)
> most likely a dupe of Bug 328428 , but somehow this seems to have regressed
> further.
> 
> Disable Talkback if you don't want to crash (currently trunk is stable enough
> to do w/o talkback)
> 
forget this comment

Confirmed (TB17727866E - TB17713622K - TB17731032K)
But those crashes happens not only on startup they are random. So description needs an update. Additionally, should be critical or at least major IMHO.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1 ID:2006041810 [cairo]
Incident ID: 17718628
Stack Signature	ntdll.dll + 0x106c3 (0x7c9506c3) 553522f3
Product ID	FirefoxTrunk
Build ID	2006041810
Trigger Time	2006-04-18 18:56:09.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	ntdll.dll + (000106c3)
URL visited	
User Comments	
Since Last Crash	5 sec
Total Uptime	13 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
ntdll.dll + 0x106c3 (0x7c9506c3)
MSVCR80.dll + 0x4ce9 (0x78134ce9)
0x06f06800

I know reporter says that Talkback makes no difference, however, I've had talkback disabled because of  Bug 328428 and am not getting any crash at all
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
(In reply to comment #4)
> I know reporter says that Talkback makes no difference, however, I've had
> talkback disabled because of  Bug 328428 and am not getting any crash at all

I tried with talkback disabled and got this crash. The bug summary is innacurate (I repeat myself sorry) see TB17727866E (Since Last Crash 2098 sec; i.e. 35 min)  


Regis, can you decribe the crash please ?
Is it anywhere like  Bug 328428 ?

in Bug 328428 , Talkback pops up, but the browser doesn't die right away.
Sometime it actually a minutes before it fades, and during a part of that period you can actually still browse.
(In reply to comment #6)
> Regis, can you decribe the crash please ?
> Is it anywhere like  Bug 328428 ?
> 
> in Bug 328428 , Talkback pops up, but the browser doesn't die right away.
> Sometime it actually a minutes before it fades, and during a part of that
> period you can actually still browse.
Here I get a "this program is a bad boy" message box, I hit close and talkback pop up (or not if disabled). 
Until now, I didn't get this crash again, so this is what I remember.  


(In reply to comment #7)
> (In reply to comment #6)
> > Regis, can you decribe the crash please ?
> > Is it anywhere like  Bug 328428 ?
> > 
> > in Bug 328428 , Talkback pops up, but the browser doesn't die right away.
> > Sometime it actually a minutes before it fades, and during a part of that
> > period you can actually still browse.
> Here I get a "this program is a bad boy" message box, I hit close and talkback
> pop up (or not if disabled). 
1. don't close that windows message box
2. just leave talkback open but try to continue to browse, FF will eventually close itself in a gently manner (that's a Bug 328428 signature)

> Until now, I didn't get this crash again, so this is what I remember.  
> 
This is so Bug 328428


(In reply to comment #8)
> This is so Bug 328428
I don't know. Browser is unusable when the crash occurs. I had two more TB17744470E (16340 sec uptime!!!). That's definitly not a startup crash. 


I just looked at a movie Régis made of the crash and it looks different from Bug 328428, here TB pops up after the crash, while in 328428 TB pops up well before FF crashes
I started seeing this around Build ID:2006041810 too, but after some sleuthing was able to get back to stable by disabling Session Manager 0.4.  SessionSaver seems to be working fine with no crashes so far, just an fyi.

In tandem with Session Manager, I noticed this bug happened alot when I middle-click on links or the home toolbar button, not sure if it helps??

TB17746088Y
TB17745647H
Mel or Régis, I have the following builds:

20060417_1021pdt cairo
20060417_1252pdt cairo
20060417_1554pdt non-cairo
20060417_2226pdt non-cairo
20060418_0301pdt non-cairo
20060418_0905pdt non-cairo
20060418_1034pdt non-cairo
20060418_1134pdt cairo (nightly)

If you can easily reproduce the crash I could gmail them to you to narrow down the regressionwindow
(In reply to comment #12)
> Mel or Régis, I have the following builds:
> [...]
> If you can easily reproduce the crash I could gmail them to you to narrow down
> the regressionwindow
Here I can't reproduce, it happends randomly. 


(In reply to comment #6)
> Regis, can you decribe the crash please ?
> Is it anywhere like  Bug 328428 ?
> 
> in Bug 328428 , Talkback pops up, but the browser doesn't die right away.
> Sometime it actually a minutes before it fades, and during a part of that
> period you can actually still browse.
> 

in my case, when the crash happens,
click Firefox-shortcut icon, only titlebar of browser appears, then it disappears,
talkback pops up.
I cannot continue to browse.
My crashes (TB17775953X, TB17740535M, TB17743782Z, TB17766220H, TB17767653K, TB17769264X, TB17730731G) always happened immediately on start before browser windows is usable. I got only one crash in the last 6 months while browsing, related to quicktime plugin. All my other crashes are either on start or on close of firefox.

I could solve the start crash here (till now, I hope it's permanently) by disabling all three auto "search for update" functions in prefs.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1) Gecko/20060420 Minefield/3.0a1 ID:2006042011 [cairo]
Can anyone reproduce this bug on a non-cairo build
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/

based on comment #15 the last comment this bug may be in the wrong component

(In reply to comment #15)
> I could solve the start crash here (till now, I hope it's permanently) by
> disabling all three auto "search for update" functions in prefs.

already unchecked three "check for updates" in Options>Advanced "Update".
but Crash happenes.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060420 Minefield/3.0a1 ID:2006042005 [cairo]
Could be due to checkins for bug #312238. On a Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060421 Firefox/3.0a1 ID:2006042109 I compiled I get a bunch of 
###!!! ASSERTION: nsUUIDGenerator not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file c:/mozilla/mozilla/xpcom/base/nsUUIDGenerator.cpp, line 53

 and

!!!!! XPConnect wrapper thread use error...
  XPConnect WrappedNative is being accessed on multiple threads but the underlying native xpcom object does not have a nsIClassInfo with the 'THREADSAFE' flag set
  wrapper: [object nsXPCComponents @ 0x359dfa8 (native @ 0x359df40)]
Additionally, when run under VC8 Express debugger, windows break on a lot of malloc, free, ... by himself stating there's HEAP corruption.
Regis, could you spin off comment 19 into a separate bug?  I'd love to see the stack for that assertion.

Is there a reason this is in Thebes?  I see nothing obvious to indicate that cairo is at fault here...
Flags: blocking1.9a1?
Depends on: 328428
(In reply to comment #20)
> Regis, could you spin off comment 19 into a separate bug?  I'd love to see the
> stack for that assertion.
No problem. Bug #334983


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060429 Minefield/3.0a1 ID:2006042910
TB18112850Q
Attached file Possible stack — 
I've been hitting this crash a lot, so I spun up a debug build to try and reproduce it there. When I crash on startup, this is the stack I see.

Also, I never crash on startup if all extensions are disabled. I hit it *a lot* if Nightly Tester Tools is enabled, however. No idea if it's Mozilla's fault, the extension's, or just a coincidence...
Attached file Assertions — 
Also, I see the following assertions and other output immediately before the crash.
Er... Could it be that we never call OpenArchive?  Or pass it a null fd?  That would mean we never call PL_INIT_ARENA_POOL.  Is calling PL_FINISH_ARENA_POOL on a pool we never inited safe?
:( i thought i commented on a bug like this. the one i was looking at involved closearchive in a destructor where i decided that there's an nsimethodimp path to closearchive, both would destroy the arena w/o making any obvious markings that the arena shouldn't be used.
Component: GFX: Thebes → Networking
QA Contact: thebes → networking
I'm on trunk since a few days, and it worked for me until now. With the current nightly (see below for build ID), I have random crashes at startup (before the main window is fully drawn and becomes usable).

Crashes started to occur before I installed NTT, and continued after I installed it. Talkback was disabled. I reinstalled with Talkback, here's the first one I got (identical to the other ones referenced, and, I fear, utterly useless):

TB18366116M

Happens with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060505 Minefield/3.0a1 ID:2006050511 [cairo]

Worked for me with previous nightlies.

My system is Windows XP SP2 on a Pentium D with 1GB RAM.

there's a patch in bug 336654 that should fix the stack from comment 23.  the patch got checked in as part of bug 336593
Depends on: 336654
No longer depends on: 336654

*** This bug has been marked as a duplicate of 336593 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: