Closed
Bug 22026
Opened 25 years ago
Closed 25 years ago
Reproducible mozilla crash in XPTC_InvokeByIndex (?)
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: stephena, Assigned: trudelle)
References
()
Details
(Whiteboard: [TESTCASE])
Attachments
(3 files)
I have found a reproducible "executed invalid instruction" crash with build
1999121612 on Win95.
Steps to reproduce:
Goto URL: http://register.uah.edu
Page will spawn a new window.
Wait for spawned window to complete loading.
Click on "Login to Student Services" graphic
Notice new page has Student ID and PIN input boxes.
Click on Student ID text field as if to enter Student ID.
Notice text cursor WILL NOT appear in text box.
Click on PIN text box are as if to type pin.
Notice text cursor WILL appear in text box.
Without typing, click on Student ID text field.
Mozilla has executed an invalid instruction in module <random module> @ ...
I'm going to try and get the HTML code behind that page and boil it down to see
if there's a simple testcase in there. I'm really tired though so it might be
tomorrow evening before I get the testcase done.
|
Reporter | |
Comment 1•25 years ago
|
||
Sometimes it registers as an invalid instruction executed and sometimes it
crashes with an invalid page fault. I've seen ENDER.DLL come up several times
as the module, but I've also seen <unknown> come up many times.
|
|
Reporter | |
Comment 2•25 years ago
|
||
It appears to be a CSS problem. In trying to boil down to a testcase I've
found simply removing the exteral style-sheet reference from the HTML causes
the problem to disapear. I may have a testcase tonight afterall.
|
|
Reporter | |
Updated•25 years ago
|
Whiteboard: [TESTCASE]
|
|
Reporter | |
Comment 3•25 years ago
|
||
I have changed the URL to point to a simple testcase. The test case is an HTML
file and an external CSS file. The HTML is as follows:
<HTML>
<HEAD>
<TITLE>Title</TITLE>
<LINK REL="stylesheet" HREF="style.css" type="text/css">
</HEAD>
<Body>
Click in the first text box, then in the second, then in the first again.
<Form method="post" name="loginform">
<Table class="input">
<tr>
<td><input type="text" name="SID"></td>
</tr>
<tr>
<td><input type="password" name="PIN"></td>
</tr>
</Table>
</Form>
<SCRIPT LANGUAGE="JavaScript">
document.loginform.SID.focus();
</SCRIPT>
</Body>
</HTML>
The CSS file (style.css) is simply an empty file with a blank line.
The bug is dependant on a couple of factors. There must an external style
sheet reference. Alltough, as you will note, the style sheet need not have
anything in it. The second thing the bug depends on is that Javascript at the
end setting focus to the first text input box.
Since this bug requires both Javascript and an external CSS I'm not sure what
the appropriate module is so I'm leaving as Browser-General for someone more
versed than I to decide.
|
||
Comment 4•25 years ago
|
||
Wooooh!! Cool bug, stephena. And again great test case. Your test case
generates the crash everytime. [Although, I can crash by just Alt-Tabbing the
another window over Mozilla, and then Alt-Tabbing Mozilla to the front again.
I have two dr. watson stack dumps that I will attach, plus the output of
the console window when, instead of crashing, Mozilla just "vanished" in
a split second, leaving this in the console window:
failed to set the page title.
Document file:///c:/temp/foobar9.html loaded successfully
Document: Done (1.893 secs)
nsXULKeyListenerImpl::Init()
runtime error R6025
- pure virtual function call
C:\JohnStuff\mozbin\moz\bin>
The two stack dump both have 'xpcom!XPTC_InvokeByIndex' called from
'NSGetModule' near the very top of the call stack, so this is XPConnect.
I'm using 1999121508 on WinNT SP4.
stephena notes above that he is using 1999121612 on Win95p
|
|
||
Comment 5•25 years ago
|
||
|
|
||
Comment 6•25 years ago
|
||
|
|
||
Comment 7•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Summary: Reproducible mozilla crash → Reproducible mozilla crash in XPTC_InvokeByIndex
|
|
Reporter | |
Comment 8•25 years ago
|
||
Thank you for the stack traces 3jrgm. I had not noticed the alt-tab causing the
crash, but now that you mention it, on build 1999121712 I am seeing it as well.
Thanks for pointing that out!
|
|
Reporter | |
Comment 9•25 years ago
|
||
Could bug# 20333 be related to this? Looks similar in testcase. That bugs
testcase does not crash my latest build, but the stack trace in their
description does show a XPTC_InvokeByIndex. Hmmm....
|
|
||
Updated•25 years ago
|
Summary: Reproducible mozilla crash in XPTC_InvokeByIndex → Reproducible mozilla crash in XPTC_InvokeByIndex (?)
|
|
||
Comment 10•25 years ago
|
||
I agree that the testcase for bug #20333 is quite similar to the one for this
page (a simple page, two textboxes, js calling focus() during load or
onload()). However, the call stack is really not the same (I speculated that
this bug was XPConnect related because XPConnect machinery was at top of stack,
but I'll stop speculating as it's beyond my depth).
[Note to stephena: XPTC_InvokeByIndex is the pivot function in calling XPCOM
components from XUL js functions, so XPTC_InvokeByIndex will appear in most
call stacks somewhere -- [and I hope I at least got that right ;)]).
|
||
Updated•25 years ago
|
Assignee: leger → jband
Component: Browser-General → XPConnect
|
|
||
Comment 11•25 years ago
|
||
XPConnect?
|
|
Reporter | |
Comment 12•25 years ago
|
||
As of build 1999121915 the behaviour described in the original bug statement
(clikcing between the input boxes) appears fixed. The secondary charechteristic
of crash when alt-tabbing away and back to mozilla does still happen though.
|
||
Updated•25 years ago
|
Component: XPConnect → XUL
|
|
||
Comment 13•25 years ago
|
||
This WORKSFORME. I can't get this to crash at all in a new build. I have
debug and release Win32 builds I built from 18 Dec that I tried on NT
and Win95. No crashes for me at all. Although alt-tabbing to another app and
back can get it into a state where there are flashing cursors in both edit
boxes.
I really doubt that this is a problem with XPTC_InvokeByIndex itself. That code
does (unintentionally) make a sort of stack frame wall that the debugger and Dr
Watson can not always traverse. So it is possible that when walking the stack
from either direction such tools will stop as XPTC_InvokeByIndex even though
there are many other unseen stack frames. It is also possible that
XPTC_InvokeByIndex is being told to invoke a method on an object which does not
have such a method.
I'm going to throw this over the wall (again?) into XUL.
|
|
||
Updated•25 years ago
|
Assignee: jband → trudelle
|
|
||
Comment 14•25 years ago
|
||
reassigning to XUL bug owner
|
Assignee | |
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Component: XUL → Style System
Resolution: --- → WORKSFORME
|
|
Assignee | |
Comment 15•25 years ago
|
||
Resolving as wfm using today's build on win98. Please reopen if there are other
steps required to reproduce. The Alt-tab is a separate problem, please file a
separate bug rather than morphing this one to cover it.
changing component to style system, since there is no XUL involved. CC'ing
kmcclusk because HTML forms controls are involved.
|
||
Comment 16•25 years ago
|
||
Updating QA Contact for a verification.
|
|
Reporter | |
Comment 17•25 years ago
|
||
Alt-Tab failure submitted as bug 22228.
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 18•25 years ago
|
||
Using 1/13 build, verified WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•