Closed Bug 303606 Opened 19 years ago Closed 17 years ago

Crash in DOMTS level 1/html HTMLFormElement10

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bc, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: crash, regression)

Attachments

(2 files)

level1:iframe:text/html FF 1.5b crash in HTMLDocument17
(deleted), text/plain
Details
level1:iframe:text/html FF 1.5b crash in HTMLFormElement10
(deleted), text/plain
Details 
I can reproduce a crash in DeerPark 2005-08-05/winxpsp2 nightly running the DOM
TS Level 1 HTML with an IFRAME loader for text/xml at HTMLFormElement10.

This may be a symptom of a larger regression. My morning test run (with some
assertion patches) hung in DOM Level 1 Core with an IFRAME loader for text/html
at hc_attrcreatetextnode.

The last time I ran this test on 2005-07-29, the test ran to completion. 

I can't get a stack at the moment but will as soon as possible.
This should block beta.
Flags: blocking1.8b4?
nsQueryInterface::operator()(const nsID & {...}, void * * 0x0012ee00) line 47 +
21 bytes
nsCOMPtr<nsISHContainer>::assign_from_qi(nsQueryInterface {...}, const nsID &
{...}) line 1232 + 17 bytes
nsCOMPtr<nsISHContainer>::nsCOMPtr<nsISHContainer>(nsQueryInterface {...}) line 646
nsDocShell::WalkHistoryEntries(nsISHEntry * 0x0431b6c0, nsDocShell * 0x04419048,
unsigned int (nsISHEntry *, nsDocShell *, int, void *)* 0x010e7e30
nsDocShell::SetChildHistoryEntry(nsISHEntry *, nsDocShell *, int, void *), void
* 0x0012eea4) line 7494
nsDocShell::SetChildHistoryEntry(nsISHEntry * 0x0431b6c0, nsDocShell *
0x04419048, int 0x00000000, void * 0x0012eeec) line 7667 + 22 bytes
nsDocShell::SetHistoryEntry(nsCOMPtr<nsISHEntry> * 0x0460c13c, nsISHEntry *
0x046c8ba0) line 7713 + 19 bytes
nsDocShell::Embed(nsDocShell * const 0x0460c074, nsIContentViewer * 0x046ce4f0,
const char * 0x011518ad, nsISupports * 0x00000000) line 4464
nsDocShell::CreateContentViewer(nsDocShell * const 0x0460bfb0, const char *
0x0467c1b0, nsIRequest * 0x0467c0c8, nsIStreamListener * * 0x0467c200) line 5476
+ 38 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x0460c5d0,
const char * 0x0467c1b0, int 0x00000001, nsIRequest * 0x0467c0c8,
nsIStreamListener * * 0x0467c200, int * 0x0012f088) line 130 + 30 bytes
nsDocumentOpenInfo::TryContentListener(nsIURIContentListener * 0x0460c5d0,
nsIChannel * 0x0467c0c8) line 774 + 66 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x0467c0c8, nsISupports *
0x00000000) line 500 + 57 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0467c1f0,
nsIRequest * 0x0467c0c8, nsISupports * 0x00000000) line 345 + 16 bytes
nsInputStreamChannel::OnStartRequest(nsInputStreamChannel * const 0x0467c0cc,
nsIRequest * 0x0467c258, nsISupports * 0x00000000) line 361
nsInputStreamPump::OnStateStart() line 381 + 42 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x0467c25c,
nsIAsyncInputStream * 0x0467c358) line 337 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x0467c974) line 120
PL_HandleEvent(PLEvent * 0x0467c974) line 688 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b4d748) line 623 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x00b4d680) line
417 + 12 bytes
nsWindow::DispatchPendingEvents() line 4195
nsWindow::ProcessMessage(unsigned int 0x00000200, unsigned int 0x00000000, long
0x004c01e8, long * 0x0012faac) line 4532
nsWindow::WindowProc(HWND__ * 0x003c032c, unsigned int 0x00000200, unsigned int
0x00000000, long 0x004c01e8) line 1418 + 27 bytes
USER32! 77d48734()
USER32! 77d48816()
USER32! 77d489cd()
USER32! 77d48a10()
nsAppShell::Run(nsAppShell * const 0x00dafcb0) line 135
nsAppStartup::Run(nsAppStartup * const 0x00dafc10) line 145 + 26 bytes
XRE_main(int 0x00000003, char * * 0x003f7868, const nsXREAppData * 0x0042201c
kAppData) line 2322 + 35 bytes
main(int 0x00000003, char * * 0x003f7868) line 61 + 18 bytes
mainCRTStartup() line 338 + 17 bytes

-	this	0x0012ee0c
-	  mRawPtr	0x0431b6c0
-	    __vfptr	0x0431b718
	      [0]	0x046e3660
	      [1]	0x0431b6c0
	      [2]	0x002e7490 handleTimerEvent(TimerEventType *)
-	aIID	{...}
	  m0	0x65281ba2
	  m1	0x988a
	  m2	0x11d3
+	  m3	0x011335a0 "½Ç"
	answer	0x0012ee00
	status	0x00000000
Assignee: general → mrbkap
for a similiar crash stack see bug 304639
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050814 SeaMonkey/1.0a

I'm crashing reproducible on bug 304639 but I reproducible don't crash here.

As I'm on 800x600 screen resolution I was missing a horizontal scrollbar to
reach the input for 'Setup page timeout:', I only saw 'Setup page tim' at the
right edge of the screen, and remembered tabbing may be a way to see if there
was an input (just before using DOM Inspector)
WFM Seamonkey trunk build 2005081505 on WinXP.
Flags: blocking1.8b4? → blocking1.8b4+
Bob, can you still reproduce this? I don't see a crash visiting the URL in the
testcase (and we pass the test to boot). I'll see if I can run the other tests
in the testsuite overnight to see if that shows anything.
*** Bug 304639 has been marked as a duplicate of this bug. ***
Blake, I can crash bug 304639 reproducably in a debug Linux build.
OS: Windows XP → All
(In reply to comment #6)
> Bob, can you still reproduce this? 

Yes. 
In a nightly 1.5 build from 2005-08-16 on winxpsp2 I:
a) hang when running the full set of tests when I reach this test
b) crash when running the individual test
In a debug 1.5 build from 2005-08-15 on winxpsp2 I:
a) crash with the same stack.
from Bug 304639 comment 6:
Regression: wfm 1.8b4: 2005081006 -- crash 1.8b4: 2005081106
Bob, could you try the patch in bug 304639 and see if it helps?
(In reply to comment #12)
> Bob, could you try the patch in bug 304639 and see if it helps?

I applied it to a 1.5 tree that was checked out 2005-08-14 PM and still get the
same behavior on the full run with the following assertions:
###!!! ASSERTION: oops, history trees are out of sync: 'destEntry', file 

c:/work/mozilla/builds/ff/1.5-test/mozilla/docshell/base/nsDocShell.cpp, line 7666
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../dist/include/xpcom\nsCOMPtr.h, line 849

I am in the process of updating rebuilding my 1.5 and 1.5 test trees. I let you
know how it goes with them.
A fix for bug 304639 has been checked in on trunk and 1.8 branch.
Please test if it fixed this one as well when builds are available.
(In reply to comment #14)
> A fix for bug 304639 has been checked in on trunk and 1.8 branch.
> Please test if it fixed this one as well when builds are available.

The dom level1, iframe, text/xml tests run to completion in Firefox 1.5 and 1.6
nightly builds from today and in optimized cvs builds from yesterday after the
patch was checked in. However my debug builds (trunk and branch) from yesterday
still hang on each of the test suites for HTMLFormElement10 with the following
asserts:

###!!! ASSERTION: oops, history trees are out of sync: 'destEntry', file
mozilla/docshell/base/nsDocShell.cpp, line 7680

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../dist/include/xpcom\nsCOMPtr.h, line 849

The second assert appears to be more general and was introduced recently. Not
sure about the first one though.
(In reply to comment #15)

I load the URL and click "Run" and that works fine for me in a Linux debug
build (no assertions) -- is there anything else I need to do to run these tests?
(In reply to comment #16)

These may be Windows only. I currently don't have a Linux setup to test with but
hope to have one in the next few days. 
I also, cannot reproduce anything on Linux. I'll try my windows machine later
today to see if that shows me the assertions.
On my Windows box on a fully updated trunk build, the test ran through to
completion without any problems. When I hit alt+<-, however, I started getting
unhappy assertions from docshell (child index out of range). I'll look more at
those tomorrow, though I suspect I'm still not hitting the same problem that Bob is.
Flags: blocking1.8b5+
Flags: blocking1.8b5+
Flags: blocking1.8b5+ → blocking1.8b5-
Isn't this WFM?
yep. No crashes on linux for any of the dom tests.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: