Closed Bug 357770 Opened 18 years ago Closed 16 years ago

crash after first startup with talkback enabled [@ntdll.dll], no crash if talkback disabled

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: wildmyron, Unassigned)

Details

(Keywords: crash)

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061023 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061023 Minefield/3.0a1

After updating Minefield or installing from a zip build Minefield crashes when I try to switch tabs. This seems to only happens after the first startup for that build and then won't happen until I update again.

Reproducible: Sometimes

Steps to Reproduce:
1. Install Minefield or update.
2. Startup (or restart after update)
3. Switch tabs.

Actual Results:  
Crash. Sometimes talkback comes up, sometimes it doesn't.

Expected Results:  
Not crash

I have seen it with 22006102104 22006102204, 22006102304 and possibly 22006101804 (slightly different, still changing tabs). I've tested in a fairly clean profile, the only changes being multiple homepages, proxy settings and a few confirmation and warning dialog prefs toggled.
Here are some talkback ID's. I'm afraid they are fairly useless.

TB24913073K (2006102204)
TB24912379Q (2006102104)
TB24753013H (2006101804)

2006102304 Just crashes without talkback coming up so no TB.

I'm going to try to find a regression range and I'm prepared to run a debug build if it would be worthwhile.

I found that the crash when switching tabs only occurs if I enter proxy settings and provide a password (I am behind an authenticated proxy). With a completely clean profile I can still cause a crash by doing a few different actions such as 

TB24959226H  going to Help -> About
TB24959370Y  exit Firefox

Other times (with the proxy settings set) the tab switching won't cause a crash, but other actions will:

TB24962934W  Tools -> Options
TB24962318H  Login to webmail

I picked out a few of the more interesting stack traces. Quite a few of the others just have ntdll.dll All of them have one thing in common: Fx crashes within 20 seconds of startup during the first run after install. None of these actions make Fx crash for me at other times. If I leave it alone for a while then it won't crash, and when I start up after the crash I also can't get it to crash. This might be a dupe of Bug 340816 but I can't get the 2006101721 build to crash in this way, and that bug is from June.

I've made some progress with this.

Firstly it doesn't seem recent, I've had the 2006100304 build crash in a similar way. Still need to investigate further back. I think the 2006101721 build doesn't crash because it was a respin (no talkback).

I found it doesn't crash in safe mode and narrowed it down to talkback. The interesting thing is the following sequence of events (with 2006102104 build):

1. Fairly clean profile.
2. Start Minefield
3. Disable Talkback
4. Restart Minefield
5. Quit Minefield
6. Delete install directory and unzip same build
7. Start Minefield, do stuff, no crash.
8. Enable Talkback
9. Restart Minefield
10. Do stuff, crash.

"Stuff" can be any of create and switch tabs, Open the options dialog and change settings, Help -> About, or interact with webpages.

Can someone explain what talkback might be doing the first time it is loaded that could cause a crash?

Lastly, this might be related to Bug 328428. I will try builds from shortly after it was resolved and work from there.
Keywords: crash
Summary: crash when switching tabs after first startup [@ntdll.dll] → crash after first startup with talkback enabled [@ntdll.dll]
kindly change to firefox version tag from "unspecified" to "trunk"
Version: unspecified → Trunk
The behaviour of this bug has changed somewhat about a week ago. I first noticed the change with the 2006111304 trunk nightly (but i hadn't updated for some days). Since then the crash happens during startup - before Firefox opens. The talkback IDs are a little more consistent. Here are some recent ones from the past week

TB25971570M
TB26075492M
TB26330395E

I've also noticed the following:
* Before Fx crashed immediately on startup I would see error messages like this in the js console:

Failed to load XPCOM component: %INSTALLDIR%\extensions\talkback@mozilla.org\components\BrandRes.dll

and similar messages for the other files in the talkback@mozilla.org/components directory. I didn't see these messages on subsequent startups.

* This machine has WinXP SP1. All the other machines I've tested on have SP2

* I found that simply disabling talkback and then enabling it again will cause a crash on the following startup.

* The stack points to the talkback component causing the crash somehow. I believe it has something to do with the way extensions are handled when they are first recognized but I have no idea about what is supposed to happen.

Sample talkback:

Stack Signature    ntdll.dll + 0x33aed (0x77f83aed) 7b6b4c81
Product ID         FirefoxTrunk
Build ID           2006112105
Trigger Time       2006-11-21 18:21:16.0
Platform           Win32
Operating System   Windows NT 5.1 build 2600
Module             ntdll.dll + (00033aed)
URL visited	
User Comments      Starting up after manually applying partial update (first start)
Since Last Crash   1 sec
Total Uptime       1 sec
Trigger Reason     Access violation
Source File, Line No.	N/A
Stack Trace 	
ntdll.dll + 0x33aed (0x77f83aed)
ntdll.dll + 0x8cca (0x77f58cca)
FULLSOFT.DLL + 0xf625 (0x0174f625)
FULLSOFT.DLL + 0x10cf7 (0x01750cf7)
FULLSOFT.DLL + 0xed36 (0x0174ed36)
FULLSOFT.DLL + 0xedb2 (0x0174edb2)
ntdll.dll + 0xb42c (0x77f5b42c)
ntdll.dll + 0x129df (0x77f629df)
kernel32.dll + 0x14af8 (0x77e74af8)
MSVCR80.dll + 0x298e (0x6009298e)
MSVCR80.dll + 0x2a36 (0x60092a36)
Arie, can you reproduce this with a completely new profile ?
(sust rename the old profiledir and let FF create a new 1 on startup)
Peter, I test this with separate, clean profiles. I try to avoid messing with my regular profiles.

The current builds don't seem to crash on startup after update any more, just within a few minutes - associated with a variety of actions as described earlier. Here is the behaviour I get with the current nightly - tested with 2006-11-26-04-trunk build.

1) Clean install of Minefield from zipfile
2) Create new profile (Testing) with profile manager
3) Start Minefield with "firefox -p Testing"
4) Dismiss default browser dialog
5) Switch tabs 1 -> 2 -> 1
6) Tools -> Options... (crash)

The QFA tool comes up and as it usually does with this crash, Minefield hangs around (unresponsive) for about 15 seconds. TB26542549W

7) Start Minefield with Testing profile
8) Do stuff (no crash)
9) Disable Talkback
10) Quit Minefield
11) Start Minefield with Testing profile
12) Enable Talkback
13) Quit Minefield
14) Start Minefield
15) Switch tabs, open and close options dialog, Help -> About, History -> Show in Sidebar (crash)

TB26543045M

I should note that I am behind an authenticated proxy so no actual page loading took place with these tests.

I find this is more reproducible when I have a clean profile with only proxy settings and multiple home pages set. By more reproducible I mean that switching tabs is more likely to cause a crash. Minefield will always crash on this machine either after update or after enable talkback when I interact with it in the first few minutes after startup. The exact sequence of events is not consistent, nor is the time from startup to crash.

I've noticed that at least one other person experienced the fullsoft.dll crash on startup I mentioned in comment #5 . Is it possible to contact this user in any way?

Extract from Talkback server Win32 Smart Analysis:

==============================================================================
     Count   Offset    Real Signature
[ 5   ntdll.dll + 0x1d24 (0x77f41d24) 69dd4e26 - FULLSOFT.DLL + 0xf625 (0x01daf625) ]
 
     Crash date range: 16-NOV-06 to 20-NOV-06
     Min/Max Seconds since last crash: 0 - 1
     Min/Max Runtime: 0 - 1
 
     Count   Platform List 
     5   Windows XP [Windows NT 5.1 build 2600] 
 
     Count   Build Id List 
     1   2006111904
     1   2006111804
     1   2006111704
     1   2006111611
     1   2006111604
 
     No of Unique Users        1
 
 Stack trace(Frame) 

	 ntdll.dll + 0x1d24 (0x77f41d24)  
	 ntdll.dll + 0x1dc9 (0x77f41dc9)  
	 FULLSOFT.DLL + 0xf625 (0x01daf625)  
	 FULLSOFT.DLL + 0x10cf7 (0x01db0cf7)  
	 FULLSOFT.DLL + 0xed36 (0x01daed36)  
	 FULLSOFT.DLL + 0xedb2 (0x01daedb2)  
	 ntdll.dll + 0x2572a (0x77f6572a)  
	 ntdll.dll + 0x3631 (0x77f43631)  
	 kernel32.dll + 0x14acd (0x77e54acd)  
	 MSVCR80.dll + 0x298e (0x7813298e)  
	 MSVCR80.dll + 0x2a36 (0x78132a36)   
 
 
==============================================================================

Corresponding TBID's
TB26252976
TB26195759
TB26143813
TB26128995
TB26089342
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/2007011504 Minefield/3.0a2pre

Arie: does this sill happen with a latest trunk build ? Does this also happen with a .exe Installer File ?
Also, have you tried with a new profile? 

dupe of bug 340816 or bug 328428.  
Tracy, in comment #7 the reporter says he's using a new profile.
(In reply to comment #9)
> Arie: does this sill happen with a latest trunk build ? Does this also happen
> with a .exe Installer File ?

Yes. See for example TB28392937 (updated build, day to day profile)
When I tried the installer I also get crashes after the first startup and after enabling Talkback but the crash is silent. No Talkback or application errors, the process just disappears.


(In reply to comment #10)
> Also, have you tried with a new profile? 
> 

Yes, and I decided to look into this again. As I mentioned in comment 7 the crash is harder to reproduce with a clean profile. I often get a different stack (always ending in ntdll.dll) and occasionally it won't crash while interacting. If this happens I then get an application error when I exit Firefox:

'The instruction at "0x77f83907" referenced memory at "0x0179029c". The memory could not be written.'

According to WinDBG 0x77f83907 is within an ntdll.dll function: ntdll!RtlpCoalesceFreeBlocks

Some of the talkback ID's from testing today's nightly:
TB28428495X
TB28432182Q
TB28432309M

I don't really know where to go. This is the only machine I see this crash on (out of three I use regularly). One last thing that might be useful is I manged to catch one of the crashes with WinDBG:

(350.91c): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=01790000 ecx=00000000 edx=002bb090 esi=002ba658 edi=002bb090
eip=77f83aed esp=037ffd3c ebp=037ffd48 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!RtlpCoalesceFreeBlocks+0x2f1:
77f83aed 8901            mov     dword ptr [ecx],eax  ds:0023:00000000=????????
0:012> kP
ChildEBP RetAddr  
037ffd48 77f58cca ntdll!RtlpCoalesceFreeBlocks+0x2f1
037ffe1c 0176f625 ntdll!RtlFreeHeap+0x28c
WARNING: Stack unwind information not available. Following frames may be wrong.
037ffe64 01770cf7 FULLSOFT!FCAssertInternal1+0xaa07
037ffe70 0176ed36 FULLSOFT!FCAssertInternal1+0xc0d9
037ffe78 0176edb2 FULLSOFT!FCAssertInternal1+0xa118
037ffe98 77f5b42c FULLSOFT!FCAssertInternal1+0xa194
037ffeb8 77f629df ntdll!LdrpCallInitRoutine+0x14
037fff34 77e74af8 ntdll!LdrShutdownThread+0xdb
037fff6c 6009298e kernel32!ExitThread+0x3e
037fff74 600929af MSVCR80!_endthreadex(
			unsigned int retcode = 0x60092a36)+0x1f [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 412]
037fffac 60092a36 MSVCR80!_callthreadstartex(void)+0x20 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
037fffb4 77e7d28e MSVCR80!_threadstartex(
			void * ptd = 0x00000000)+0x66 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326]
037fffec 00000000 kernel32!BaseThreadStart+0x37


(In reply to comment #10)
> 
> dupe of bug 340816 or bug 328428.  
> 
bug 328428 : No. I tried builds from around that time and none of them crashed in the way I experience currently.
bug 340816 : Possibly. But I haven't ever had a stack which looks similar to the one in bug 340816 comment 6

I did try finding a regression range but the crash behaviour became less consistent as I went further back. I believe the first build which crashes is 2006080804 or possibly 2006080704

If you need some help (I'm just a stupid end user with really lightly programming skills) what can I do? I hat my Minefield because of crashing every morning shortly after updating it (I don't even have to change tabs; I'm just waiting for the crash to start Minefield again).
(In reply to comment #14)
> If you need some help (I'm just a stupid end user with really lightly
> programming skills) what can I do? I hat my Minefield because of crashing every
> morning shortly after updating it (I don't even have to change tabs; I'm just
> waiting for the crash to start Minefield again).

Go to tools, Add-ons, and disable Talkback. That's the only thing that helps.
Since this bug does not seem to occur everywhere and therefore is only of very low importance, there is nothing else you can do at the moment.

Does this bug still occur now that trunk builds have switched from Talkback to Breakpad?
I don't know when this change took place but I haven't seen my Minefield crashing like this for a very long time now.
It has stopped crashing as soon as they switched to Breakpad. Much to my relieve!
Arie, is this crash still happening to you now that Talkback is no longer present on nightlies? If not, then you could close the bug :)
No, I haven't seen this crash since Breakpad was enabled.

I guess that makes this fixed by Bug 354980 and / or Bug 216827
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
>No, I haven't seen this crash since Breakpad was enabled.

Arie, so it stopped for you in June(ish) time frame?


(In reply to comment #7)
> Peter, I test this with separate, clean profiles. I try to avoid messing with
> my regular profiles.
> 
> 11) Start Minefield with Testing profile
> 12) Enable Talkback
> 13) Quit Minefield
> 14) Start Minefield
> 15) Switch tabs, open and close options dialog, Help -> About, History -> Show
> in Sidebar (crash)
> 
> TB26543045M
> 
> I should note that I am behind an authenticated proxy so no actual page loading
> took place with these tests.
> 
> I find this is more reproducible when I have a clean profile with only proxy
> settings and multiple home pages set. By more reproducible I mean that
> switching tabs is more likely to cause a crash. Minefield will always crash on
> this machine either after update or after enable talkback when I interact with
> it in the first few minutes after startup. The exact sequence of events is not
> consistent, nor is the time from startup to crash.
Component: General → Talkback Client
Product: Firefox → Core
QA Contact: general → chofmann
Summary: crash after first startup with talkback enabled [@ntdll.dll] → crash after first startup with talkback enabled [@ntdll.dll], no crash if talkback disabled
Version: Trunk → 1.8 Branch
(In reply to comment #21)
> > No, I haven't seen this crash since Breakpad was enabled.
> 
> Arie, so it stopped for you in June(ish) time frame?

I can't actually remember the time frame. I do recall deliberately disabling talkback and running with breakpad enabled from before it was officially enabled to work around the crash after every update. I am still uncertain whether the crash was caused by a bug in the talkback extension or in XPCOM but as I haven't seen anything similar since I don't see how it would be worth pursuing.

don't think this should be marked fixed - because breakpad is trunk only.  so the talkback issue in version 2.0 is still outstanding.  But it could become wontfix when in XX months everyone stops caring about talkback.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
(In reply to comment #23)

I haven't personally ever experienced this bug on the branch. If you want to keep this bug open do you have any evidence to support changing from trunk to branch with comment 21?
Well, when you created this bug, trunk was what is now gecko/core 1.8, which became FF 2.0. If the problem exists in 2.0 AND trunk then the appropriate version is unspec. But if you say you had it enabled on 2.0 for several months and never saw it then I suppose ver=trunk is appropriate and you are welcome to change it back

but regardless, fixed in inappropriate.  and it's not possible to prove the problme is gone because talkback stopped being packaged with trunk - there's nothing to test. unless i misunderstand what has transpired.  Eventually, when the final cleanup of talkback bugs has come, I'd guess someone will mark all the talkback bugs invalid or wontfix.

I hope that helps.
i think this should be:

version -> TRUNK
status -> INVALID
I should learn to read :)
comment 0 "gecko 1.9"
Version: 1.8 Branch → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
Crash Signature: [@ntdll.dll]
You need to log in before you can comment on or make changes to this bug.