Closed Bug 17852 Opened 25 years ago Closed 25 years ago

Previous crasher in nsListControlFrame::GetSelect

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jim_nance, Assigned: rods)

References

(
URL
)

Details

Using a 7:00 PM EST Nov 2 pull running under Red Hat Linux
6.1, I get a reproducable crash when visiting the URL:

http://www.newsalert.com/bin/story?StoryId=Cob0EubKbytaWmte&FQ=Linux&Nav=na-search-&StoryTitle=Linux

The crash occurs on line 1061 of nsListControlFrame.cpp.  Here
is the gdb output:

(gdb) frame 0
#0  0x40f2203a in nsListControlFrame::GetSelect (aContent=0x0)
    at
/home/jlnance/src/19980429/mozilla/layout/html/forms/src/nsListControlFrame.cpp:1061
1061      nsresult result =
aContent->QueryInterface(nsCOMTypeInfo<nsIDOMHTMLSelectElement>::GetIID(),
(gdb) list
1056    //---------------------------------------------------------
1057    nsIDOMHTMLSelectElement*
1058    nsListControlFrame::GetSelect(nsIContent * aContent)
1059    {
1060      nsIDOMHTMLSelectElement* selectElement = nsnull;
1061      nsresult result =
aContent->QueryInterface(nsCOMTypeInfo<nsIDOMHTMLSelectElement>::GetIID(),
1062                                                 (void**)&selectElement);
1063      if (NS_SUCCEEDED(result) && selectElement) {
1064        return selectElement;
1065      } else {
(gdb) quit
Assignee: leger → rods
Severity: normal → critical
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 17315 ***
Status: RESOLVED → REOPENED
Target Milestone: M11
Resolution: DUPLICATE → ---
Bug 17315 is fixed but this one is not using Nov. 4 build, re-opening and
putting on M11 radar. Looks similar to bug 17995
bug 17817 and bug 17900 are duplicates (I think) of this, the bugzilla query
crashers
*** Bug 17894 has been marked as a duplicate of this bug. ***
*** Bug 17995 has been marked as a duplicate of this bug. ***
Summary: browser crash → browser crash in nsListControlFrame::GetSelect
updating summary a bit
OK, here's a very simply test case to demonstrate this crash:

<html>
<head>
  <script>
    function loadFrames(){
      top.frames[1].document.open();
      top.frames[1].document.write(
        "<form>" +
          "<table>" +
            "<tr>" +
              "<td>" +
                "<tr>" +
                  "<td>" +
                    "<select>"
      )
alert("program gets here successfully");
      top.frames[1].document.write(
                      "<option VALUE='first'>steve</option>"
      )
alert("but it never gets here");
    };
  </script>
</head>

<frameset rows = "15,25" onload="loadFrames();">
  <frame src="about:blank">
  <frame src="about:blank">
</frameset>

<noframes>
  <body> <br/> </body>
</noframes>
</html>

Furthermore, the crash that I am seeing is at line 1915 instead of 1061 as
reported above.
Looking over the stack trace of bug 17817 (which shows the crash on line 1061)
and of bug 17995 (which is the one I was tracking down when it got marked as a
duplicate of this bug), they definitely are different.  So we might have two
different bugs here.  The simplified example that I included above crashes with
the stack trace of bug 17995.
I agree, they are probably two separate bugs.

Here's a further reduction of the above testcase, to eliminate framesets and
document.writing from the picture:

<html>
 <body>
   <select>
<script>dump('block parser to cause crash\n');</script>
    <option VALUE='first'>steve</option>
   </select>
 </body>
</html>
Rod, I pulled and rebuilt with your fix for this bug (17852) and bug 17995 still
exists, therefore implying it is not a dup.

Bug 17900 and 17995 have the same stack trace and are probably a separate bug.
I marked 17995 a dup of this bug so I'm going to undo my evil.  :)
Oh, I see.  The problem is that the html parser was interrupted in the middle of
a select statement.  That's obvious from Eric's example.  From my example I
couldn't figure out what it was about the second document.write that was causing
the problem.
Blocks: 18053
The problem here is that the combobox is calling "MakeSureSomethingIsSelected"
something is selected and that is calling "UpdateSelection" which causes all the
same baddness to happen that the Reset was doing.

You can't initialize the list until all frames have been created for a final
time.

I can fix this by commenting out the UpdateSelection in
MakeSureSomethingIsSelected
And I comment out the line (in nsListControlFrame)
mComboboxFrame->UpdateSelection(PR_FALSE, PR_TRUE, selectedIndex);
No longer blocks: 18053
This page is not crashing anymore, and neither is bugzilla. Was a fix checked
in? I don't get a scrollbar on this page, though.
I take back the above comments. Both this page and bugzilla are still crashing,
though somewhat intermittently. For example, bug 8673 seems to crash
consistently, while some other bugs do not.
Depends on: 18183
Summary: browser crash in nsListControlFrame::GetSelect → Previous crasher in nsListControlFrame::GetSelect
Target Milestone: M11 → M12
Added bug dependency, moved to M12 because it no longer crashes, leaving as
critical, changing Summary
Yes, based on Rods fix for the original bug here, I checked in a workaround for
bug 17995 / bug 17900 / Steve Morse's test case.  I commented out
MakeSureSomethingIsSelected in nsComboboxControlFrame::AddOption.  As a result,
comboboxes will initialize correctly, but selection will not be updated if
options are dynamically added to a combobox after init.

Sounds like Rod has the right plan.  Once bug 18183 is fixed, Reset can be
called from nsListControlFrame::AddOption after the notification is received,
and MSSIS can be called from nsComboboxControlFrame::AddOption after the
notification is received.

I'm not sure how bug 8673 is related?
*** Bug 18086 has been marked as a duplicate of this bug. ***
Component: Browser-General → HTML Form Controls
QA Contact: leger → cpratt
Updating component and QA contact.
It looks like this workaround didn't get checked into the M11 branch. Eric, can
you get it into Seamonkey_M11_Branch?

Bugzilla is still crashing on 111017 M11 branch build we got last night.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
No longer crashes with new code - Fixed
QA Contact: cpratt → elig
cpratt is out of town; QA Assigning to self.
Status: RESOLVED → VERIFIED
Using the 1999111612 (Mac OS M11), 1999111218 (Win32) and 1999111208 (Linux)
builds, confirmed that viewing all of the following:
	* the URL cited in bug report
	* the simplified test case provided by pollman on 11.04.99 at 15:44 PM
	* the test case from duplicate bug 18086

	...do not trigger a crash.

If I've missed anything, please add your $.02 and re-open. Thanks!
You need to log in before you can comment on or make changes to this bug.