91479 - doing various things with the URL bar causes mozilla to crash - Trunk [@ CopyChars1To2]

Status: VERIFIED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[Jacob Kjome]

using build 2001071903 on Win2k (SP2)

Talkback ID#:  TB33088717Q

As of this morning's builds, Mozilla crashes constantly after doing various 
things in the URL bar.  Doing things like pasting a URL in and hitting enter, 
or right clicking and the left clicking in the URL bar cause Mozilla to crash.

I haven't figured out the exact steps to reproduce this, but it is very 
reproduceable.  Spend any time with this morning's build and you will see the 
problem.

jake

Comment 1

[Ben Guthrie]

Windows NT Version 4.0 ( Build 1381: Service pack 4)

same mozilla build.

clicked on the URL to edit it, moz crashed before I had a chance

Comment 2

[Jacob Kjome]

may be related to bug 91477

Jake

Comment 3

[Asa Dotzler [:asa]]

Incident ID 33088717
Stack Signature 0x00000000 554f69ef
Bug ID
Trigger Time 2001-07-19 07:52:31
User Comments Just try right clicking in the URL bar. Then, left click in the
URL bar. Sometimes it crashes immediately. This time, after I left clicked, it
crashed after I moved the mouse off the URL bar...maybe off the browser. Very
reproduceable despite the lack
Build ID 2001071905
Product ID MozillaTrunk
Platform ID Win32
Stack Trace
0x00000000
nsAString::Equals [..\..\dist\include\nsAString.h, line 628]
nsStyleFont::CalcFontDifference
[d:\builds\seamonkey\mozilla\content\shared\src\nsStyleStruct.cpp, line 229]
nsStyleFont::CalcDifference
[d:\builds\seamonkey\mozilla\content\shared\src\nsStyleStruct.cpp, line 214]
nsStyleContext::CalcStyleDifference
[d:\builds\seamonkey\mozilla\content\base\src\nsStyleContext.cpp, line 603]
CaptureChange
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1598]
FrameManager::ReResolveStyleContext
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1688]
FrameManager::ReResolveStyleContext
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1834]
FrameManager::ComputeStyleChangeFor
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 2078]
nsCSSFrameConstructor::ContentStatesChanged
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 9798]
StyleSetImpl::ContentStatesChanged
[d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1144]
PresShell::ContentStatesChanged
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4921]
nsXULDocument::ContentStatesChanged
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 1580]
nsEventStateManager::SetContentState
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 3525]
nsEventStateManager::GenerateMouseEnterExit
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2122]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 355]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5628]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5560]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2057]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 725]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 742]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4243]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4490]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3234]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 990]
USER32.DLL + 0x2e98 (0x77e12e98)
USER32.DLL + 0x30e0 (0x77e130e0)
USER32.DLL + 0x5824 (0x77e15824)
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 424]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1181]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1481]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1499]
WinMainCRTStartup()
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

Comment 4

[Asa Dotzler [:asa]]

I'm also seeing this on win2K 071903 build.

Comment 5

[Asa Dotzler [:asa]]

Unable to complete smoketests. Crash 4 times in the first half of browser and
mailnews testing. 

Comment 6

[Ben Guthrie]

my talkback ID on this crash was TB33088279W  10:47 EDT

Comment 7

[Chase Tingley]

OS -> ALL

My Linux trunk cvs build went down in flames pasting into the url bar.

Comment 8

[Thomas Swan]

I sent some talkback dumps where this happened to me as well...

Comment 9

[Viswanath Ramachandran]

Alec's not here, reassigning to Paul. Adding Scc as its crashing in string code? 

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I doubt string code is the problem.  |Equals| is non-virtual and it looks like
it's being given a |this| of null, or the other string is a reference to |null|
(eek!, but we've seen it before).

Comment 11

[Shannon Diener]

I'm seeing this on Linux as well as HP-UX.  I've crashed the browser doing such
things as simply pressing the Home button, typing something into the URL bar, or
setting up a new mail account (this crashes the browser every time for me). 
When I set up a new mail account and get to the point where I need to type in
the server information I will see a change in layout in that dialog (if you
don't see it the first time press back and then next to get back to this window)
and after typing in this information and pressing next, the browser crashes.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just hit this in an opt windows build from a little after I checked in last 
night.  I dropped into the debugger and poked at the assembler.  The entire 
nsAString::Equals is this:

10001C6D   push        ebp
10001C6E   mov         ebp,esp
10001C70   sub         esp,0Ch
10001C73   push        esi
10001C74   mov         dword ptr [ebp-8],ecx
10001C77   mov         eax,dword ptr [ebp-8]
10001C7A   mov         eax,dword ptr [eax]
10001C7C   mov         ecx,dword ptr [ebp-8]
10001C7F   call        dword ptr [eax+14h]
10001C82   mov         esi,eax
10001C84   mov         eax,dword ptr [ebp+8]
10001C87   mov         eax,dword ptr [eax]
10001C89   mov         ecx,dword ptr [ebp+8]
10001C8C   call        dword ptr [eax+14h]      <=== CRASH
10001C8F   cmp         esi,eax
10001C91   jne         10001CC0
10001C93   mov         dword ptr [ebp-4],100695D4h
10001C9A   mov         dword ptr [ebp-4],100695D8h
10001CA1   lea         eax,[ebp-4]
10001CA4   push        eax
10001CA5   push        dword ptr [ebp+8]
10001CA8   push        dword ptr [ebp-8]
10001CAB   call        100580F2
10001CB0   add         esp,0Ch
10001CB3   test        eax,eax
10001CB5   jne         10001CC0
10001CB7   mov         dword ptr [ebp-0Ch],1
10001CBE   jmp         10001CC4
10001CC0   and         dword ptr [ebp-0Ch],0
10001CC4   mov         eax,dword ptr [ebp-0Ch]
10001CC7   pop         esi
10001CC8   leave
10001CC9   ret         4

so it looks like the problem is that the parameter |rhs| to |Equals| is a 
reference to null.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A sensible reason that could happen is if the nsFont itself is null.  (|name|
should be at offset 0 within the |nsFont|.)

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So how would |GetStyleData| return null (in the call at the beginning of
|nsStyleContext::CalcStyleDifference|)?  We know both contexts must be valid (to
some extent, anyway) since GetStyleData is virtual.

Comment 15

[R.K.Aa.]

seems it's the tooltips crashing on linux. Disable tooltips and the crash is
gone. Crash triggers here after holding mouse over any button in toolbar or
statusbar. First the tooltip appears, then i crash.

I think bug 91493 is a dup of this.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A guess would be that this might have been caused by the changes for bug 90081.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Except that some of asa's crash reports show a different stack unrelated to 
style but still related to fonts:

CopyChars1To2 [d:\builds\seamonkey\mozilla\string\obsolete\bufferRoutines.h, 
line 278] 
nsStr::StrAppend [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, line 
185] 
nsStr::StrAssign [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, line 
160] 
nsString::nsString [d:\builds\seamonkey\mozilla\string\obsolete\nsString2.cpp, 
line 101] 
nsFont::nsFont [d:\builds\seamonkey\mozilla\gfx\src\nsFont.cpp, line 51] 
nsFontMetricsWin::Init 
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsFontMetricsWin.cpp, line 416] 
DeviceContextImpl::GetMetricsFor 
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 303] 
nsTextBoxFrame::GetTextSize 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTextBoxFrame.cpp, line 760] 
DeviceContextImpl::GetMetricsFor 
[d:\builds\seamonkey\mozilla\gfx\src\nsDeviceContext.cpp, line 303] 
...

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually that is based on data from style, since nsTextBoxFrame::GetTextSize 
gets data from style...

Comment 19

[Francisco León]

I could not get this to crash in build 2001071904
trunk only?

Comment 20

[Chase Tingley]

I've backed out bug 90081 fixes from the last day in my linux cvs build, and
haven't crashed yet.

Comment 21

[Paul Chen]

backing out dbaron's fixes just to see, if that doesn't work, will try backing
out hyatt's fix for 90081

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I have hyatt's patch for bug 90081 backed out in my tree as well, and I haven't 
crashed yet either.

Comment 23

[R.K.Aa.]

*** Bug 91493 has been marked as a duplicate of this bug. ***

Comment 24

[Chase Tingley]

I've also tested mail account creation and profile creation (bug 91512) with
90081 backed out; still no crashes.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

hyatt commented out a function so that his changes from yesterday are disabled.
 This change fixes Asa's 100%-reproducable case to see the crash, so we should
probably be good for a respin now.

Comment 26

[Paul Chen]

hyatt checked in the #if 0 in nsStyleContext.cpp, marking fixed

Comment 27

[lpham]

I'm respining all three platforms in the trunk (not the branch). Loan

Comment 28

[Tracy Walker [:tracy]]

verified on respins:

windows 2001-07-19-13-trunk
linux 2001-07-19-13-trunk
mac 2001-07-19-13-trunk

Comment 29

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 91527 has been marked as a duplicate of this bug. ***

Comment 30

[Asa Dotzler [:asa]]

*** Bug 91452 has been marked as a duplicate of this bug. ***

Comment 31

[Chase Tingley]

*** Bug 91599 has been marked as a duplicate of this bug. ***

Comment 32

[Jay Patel [:jay]]

Adding topcrash and Trunk [@ CopyChars1To2] for future reference, since this
*was* a topcrasher.

Comment 33

[R.K.Aa.]

This stack has surfaced again in bug 105619