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

VERIFIED FIXED

Status

SeaMonkey
Location Bar
--
blocker
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Jacob Kjome, Assigned: David Hyatt)

Tracking

({crash, smoketest, topcrash})

Trunk
x86
All
crash, smoketest, topcrash

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

(Reporter)

Description

17 years ago
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

17 years ago
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
(Reporter)

Comment 2

17 years ago
may be related to bug 91477

Jake

Comment 3

17 years ago
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

17 years ago
I'm also seeing this on win2K 071903 build.

Comment 5

17 years ago
Unable to complete smoketests. Crash 4 times in the first half of browser and
mailnews testing. 
Severity: critical → blocker
Keywords: smoketest

Comment 6

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

Comment 7

17 years ago
OS -> ALL

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

OS: Windows 2000 → All

Comment 8

17 years ago
I sent some talkback dumps where this happened to me as well...
Alec's not here, reassigning to Paul. Adding Scc as its crashing in string code? 
Assignee: alecf → pchen
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

17 years ago
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.
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.
A sensible reason that could happen is if the nsFont itself is null.  (|name|
should be at offset 0 within the |nsFont|.)
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

17 years ago
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.
A guess would be that this might have been caused by the changes for bug 90081.
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] 
...
Actually that is based on data from style, since nsTextBoxFrame::GetTextSize 
gets data from style...

Comment 19

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

Comment 20

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

Comment 21

17 years ago
backing out dbaron's fixes just to see, if that doesn't work, will try backing
out hyatt's fix for 90081
I have hyatt's patch for bug 90081 backed out in my tree as well, and I haven't 
crashed yet either.
Assignee: pchen → hyatt

Comment 23

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

Comment 24

17 years ago
I've also tested mail account creation and profile creation (bug 91512) with
90081 backed out; still no crashes.
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

17 years ago
hyatt checked in the #if 0 in nsStyleContext.cpp, marking fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 27

17 years ago
I'm respining all three platforms in the trunk (not the branch). Loan
verified on respins:

windows 2001-07-19-13-trunk
linux 2001-07-19-13-trunk
mac 2001-07-19-13-trunk
Status: RESOLVED → VERIFIED
*** Bug 91527 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: crash
Summary: [crash] doing various things with the URL bar causes mozilla to crash → doing various things with the URL bar causes mozilla to crash

Comment 30

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

Comment 31

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

Comment 32

17 years ago
Adding topcrash and Trunk [@ CopyChars1To2] for future reference, since this
*was* a topcrasher.
Keywords: topcrash
Summary: doing various things with the URL bar causes mozilla to crash → doing various things with the URL bar causes mozilla to crash - Trunk [@ CopyChars1To2]

Comment 33

17 years ago
This stack has surfaced again in bug 105619
Product: Core → SeaMonkey
Crash Signature: [@ CopyChars1To2]
You need to log in before you can comment on or make changes to this bug.