Closed Bug 103904 Opened 23 years ago Closed 23 years ago

crash in nsComboboxControlFrame::CreateAnonymousContent

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: runyonkj, Assigned: jst)

References

Details

(Keywords: crash, topcrash, topembed, Whiteboard: [HAVE FIX])

Attachments

(1 file)

Crashing in nsComboboxControlFrame::CreateAnonymousContent() because doc is 
null...from LXR
http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsComboboxControlFra
me.cpp#2324

and from the blamelog ... jst added code to call a method on nsIDocument 
without checking the value of the pointer:
http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/
forms/src&command=DIFF_FRAMESET&file=nsComboboxControlFrame.cpp&rev2=1.126&rev1=
1.125
sorry about the broken links
Keywords: crash
Severity: normal → critical
I see nsFileControlFrame::CreateAnonymousContent and 
nsIsIndexFrame::CreateAnonymousContent share the same problem (using doc 
without checking it)


nsGfxTextControlFrame2::CreateAnonymousContent() looks like a good example to 
follow...modifications made by kin@netscape.com

http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsGfxTextControlFram
e2.cpp#1925
Forgot to mention that we are seeing this crash in an embedding client using 
the 0.9.4 branch. We'll need the fix on the branch. thanks.
What are the steps to repro this?
Calling methods on |doc| w/o checking for a non-null document pointer is
probably not the problem here, the fact that the document pointer is null is
more likely the problem, but I could of course be wrong.

I'm still on vacation (back on monday next week) so if this needs some attention
before next week this bug needs to be handed off to someone else, and as valeski
pointed out, we need to be able to reproduce this crash.
I am seeing this after a font download (for example, visiting www.korea.com), 
when the resulting page begins to render. You will probably need the embedding 
application to reproduce....Jud can help you there.
-> ftang's court.
Assignee: jst → ftang
Keywords: topembed
Blocks: 64833
roy- can you take a look at this ?
Assignee: ftang → yokoyama
Target Milestone: --- → mozilla0.9.6
Status: NEW → ASSIGNED
teruko: has this happened with embedding client-0_9_2_branch before?

dan: The OpenWindow() hasn't been changed for awhile; but I suspect
that the giving nsnull as a parent to windowWatcher may be the cause of
this crash. However, I thought we have resolved this issue awhile back.
Do we still support this case?

Here is the code we have in nsFontPackageHandler.cpp

 88 rv = windowWatch->OpenWindow(nsnull, absUrl, 
 89 "_blank",
 90 "chrome,centerscreen,titlebar,resizable", 
 91 nsnull, 
 92 getter_AddRefs(dialog));

http://lxr.mozilla.org/seamonkey/source/xpfe/components/intl/nsFontPackageHandler.cpp#88

=== adding danm, teruko to cc list.
Null parents to the window.open call shouldn't be a problem; that technique is
still used all over the place.

Oh. From Ken's 2001-10-10 07:09 comment above: does this happen only in
embedding clients? There's a known problem with embedded Gecko failing to have a
valid docshell in a newly opened window in a timely fashion. See bug 88229.

However, if that's the problem, this bug should only appear under certain
restrictive conditions. The real fix isn't going to happen on 0.92 or 0.94 -- my
patch is 50K so far, including five interface files. This bug has been kind of
patched already on those branches (see rpotts' attachments to bug 88229), but to
get the benefit of that patch the embedding client has to cooperate by
explicitly launching a synchronous load of the new window's docshell. (Note that
this should only be necessary on those two branches; on the trunk we're handling
it internally.)

So if this bug is really another facet of 88229, it should only be happening on
trunk builds of embedding clients, or on 0.92 or 0.94 branch builds of embedding
clients that haven't been tweaked as bug 88229 describes. If true, I'd close
this as a duplicate.
This is occurring in an embedded client based on the 0.9.4 branch, and no, I 
don't believe we are performing the steps to explicitly "launch a synchronous 
load of the new window's docshell". Will look further into that issue.
My initial thought about OpenWindow() was incorrect.
Embedding client doesn't call OpenWindow().  It implements its
own FontPackageHandler.  

I gut feeling is that it's got something to do with the reference counting.
The font download may be surfacing other problem.

I see in nsComboControlFrame.cpp [line 2333] like
mContent->GetDocument(*getter_AddRefs(doc));
I may be wrong; but it looks suspecious. 

and as per ftang's suggestion I am re-assigning this to jst@netscape.com

Here is the steps to reproduce in the embedding client:
1) go to URL http://www.sina.com.cn; download the font if already have not
2) go to URL http://www.korea.com; click 'Yes' to download the font
3) GPF in GKLAYOUT.DLL:
Assignee: yokoyama → jst
Status: ASSIGNED → NEW
This is very important for embed project.  

What is the status of this bug?
The status is that I don't have a embedding build where I could debug this, so
there's nothing I can do at the moment. |doc| just shouldn't be null in
nsComboboxControlFrame::CreateAnonymousContent(), something bad happened before
that which made |doc| null, but I have no idea what that was.

If someone can point me at a debug embedding build that I can get to and install
my own debug mozilla I could look into this futher, but I'd be surprised if this
is a mozilla bug. My bet is on the embedding code not playing nice with our
dialog modality story and causing re-entrancy into layout, which later on
results in a crash once the font download is done.

Ken, can you hook me up with a debug build of the client where this happens?
Please contact Jud (valeski@netscape.com) for help with building an embedding 
client.
  I still think this is caused by bug 88229. If I could reproduce this one I
could with some trouble say for certain. But I never get a "do you want to
download a korean font?" dialog. It fails somewhere deep in the intl code
because the language ID string ("ko") is less than six characters long. There
must be something I have to enable on my plain Latin OS before I can even get
that far. You guys wouldn't have any easier steps to reproduce, would you?
  PS -- a debug embedding client comes free in the debug Mozilla box. On Windows
just build Mozilla and run dist/WIN32_D.OBJ/bin/winEmbed or .../mfcEmbed. And
modality on both testbeds is pretty well-behaved.
Dan, to reproduce this you need a embed client with it's own font downloader,
mfcEmbed doesn't have one.

So I finally got a debug build of an embed client where I could test this
(thanks chack!) and it turns out (after rpotts and I scratched our heads for a
while over this problem) that this is, or at least seems, unrelated to bug 88229 :-(

The problem here is that as we're download a new font from within layout we end
up getting a WM_FONRCHANGE message which causes all current presshells to
reframe the document and one of the presshells is the previous presshell in the
window (i.e. the one that's used for painting the old document while paints are
supressed). This particular document is already halfway torn down so reframing
the document is pointless, and results in a crash. The fix we came up with is to
check in the presshell code that the document in the presshell is in a good
state before reframing the document after a font change (or any other pref
change, see
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#3052).

Patch coming up.
Attached patch Proposed fixSplinter Review
Odd.  When I tested Roy's STR with the proposed patch, there seemed to be a new 
issue.  While there was no longer a GPF upon successful download of the korean 
font, the korea site was never rendered.  The browser window title changed to 
the korean site, but the content was still that of the original chinese site.  
When I hit reload, the korean page came up properly.

Could the patch also be terminating the laying out of the page that is still 
loading?
I saw that problem both before and after writing this fix, so I don't think (and
can't see how) the attached fix would be related to that problem.
Nominating this bug to edt0.9.4.
Keywords: edt0.9.4
Unless someone objects I will check in the fix on the 094 branch as soon as I
get permission.
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
good to go for 0.9.4 checkin; thanks johnny
Keywords: edt0.9.4edt0.9.4+
Comment on attachment 55719 [details] [diff] [review]
Proposed fix

sr=rpotts@netscape.com
Attachment #55719 - Flags: superreview+
This is a topcrash in N620.  Added N620 crash [@
nsComboboxControlFrame::CreateAnonymousContent ] for tracking.

Here is a stack trace, there are no comments available yet.

Stack Trace: 

	 nsComboboxControlFrame::CreateAnonymousContent
[d:\builds\seamonkey\mozilla\layout\html\forms\src\nsComboboxControlFrame.cpp 
line 2315]
	 nsCSSFrameConstructor::CreateAnonymousFrames
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 5304]
	 nsCSSFrameConstructor::CreateAnonymousFrames
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 5278]
	 nsCSSFrameConstructor::ConstructSelectFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 4344]
	 nsCSSFrameConstructor::ConstructFrameByTag
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 4859]
	 nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7368]
	 nsCSSFrameConstructor::ConstructFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7279]
	 nsCSSFrameConstructor::ProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 11675]
	 nsCSSFrameConstructor::ConstructTableCellFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3009]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3273]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2880]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3259]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowGroupFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2771]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3253]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2652]
	 nsCSSFrameConstructor::ConstructFrameByDisplayType
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 6653]
	 nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7407]
	 nsCSSFrameConstructor::ConstructFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7279]
	 nsCSSFrameConstructor::ProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 11675]
	 nsCSSFrameConstructor::ConstructTableCellFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3009]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3273]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2880]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3259]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowGroupFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2771]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3253]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2652]
	 nsCSSFrameConstructor::ConstructFrameByDisplayType
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 6653]
	 nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7407]
	 nsCSSFrameConstructor::ConstructFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7279]
	 nsCSSFrameConstructor::ProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 11675]
	 nsCSSFrameConstructor::ConstructTableCellFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3009]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3273]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2880]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3259]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowGroupFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2771]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3253]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2652]
	 nsCSSFrameConstructor::ConstructFrameByDisplayType
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 6653]
	 nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7407]
	 nsCSSFrameConstructor::ConstructFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7279]
	 nsCSSFrameConstructor::ProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 11675]
	 nsCSSFrameConstructor::ConstructTableCellFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3009]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3273]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2880]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3259]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableRowGroupFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2771]
	 nsCSSFrameConstructor::TableProcessChild
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3253]
	 nsCSSFrameConstructor::TableProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 3185]
	 nsCSSFrameConstructor::ConstructTableFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 2652]
	 nsCSSFrameConstructor::ConstructFrameByDisplayType
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 6653]
	 nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7407]
	 nsCSSFrameConstructor::ConstructFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 7279]
	 nsCSSFrameConstructor::ProcessBlockChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp 
line 12833]
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp
line : 2315



Keywords: topcrash
Summary: crash in nsComboboxControlFrame::CreateAnonymousContent → crash in; N620 crash [@ nsComboboxControlFrame::CreateAnonymousContent ]
Comment on attachment 55719 [details] [diff] [review]
Proposed fix

r=bzbarsky
Attachment #55719 - Flags: review+
Fix checked in on trunk and branch. If this is a Netscape 6.2 topcrash, please
file a new bug on that since this is about a specific crash which does *not*
happen on Netscape 6.2
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Keywords: landed0.9.4
Ok
(removed 6.2 reference from summary.)
Summary: crash in; N620 crash [@ nsComboboxControlFrame::CreateAnonymousContent ] → crash in nsComboboxControlFrame::CreateAnonymousContent
I verified this in Embed projects with 11-08 0.9.4ec.
Status: RESOLVED → VERIFIED
Verified in the 2002-01-14-23-0.9.4ec build.
Keywords: verified0.9.4
Keywords: fixed0.9.4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: