Closed Bug 154692 Opened 22 years ago Closed 15 years ago

Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] (only if java is installed)

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 FIXED

People

(Reporter: schnirbbel, Assigned: sicking)

References

(
URL
)

Details

(Keywords: crash, regression, topcrash-, Whiteboard: [needs answer to comment 47 or should be closed][needs testcase])

Crash Data

Attachments

(3 files, 1 obsolete file)

backtrace
(deleted), text/plain
Details
win2k stack trace
(deleted), text/plain
Details
MacsBug stdlog from testcase in comment #13
(deleted), text/plain
Details 
Open the page (they do run a nice Benchmark there with chessprograms), using an
applet to show the games online in realtime.
Mozilla always crashed with the nightly build from yesterday, and with the one
from today (2002062713), after rightclicking mouse -> Page Info -> switching to
Tab "Links".
Gives an GPF, and under Details shows "JS3250.DLL", so it might be related to
JavaScript-Engine.
Reassigning to Browser-General until we can get a stack trace.
Often the top of stacks refer to JS3250.DLL, but the actual error
usually occurs lower down in the stack -

schnirbbel@gmx.de: would it be possible for you to download a
Talkback-enabled build? (see http://www.mozilla.org/releases/) 

If you can get a Talkback build to crash, please fill out a
Talkback report for us. Then after Talkback sends the crash, 
run "(install_directory)/mozilla/components/talkback.exe" and 
post the Talkback ID(s) into this bug in the "Additional Comments"
box above (then hit the "Commit" button). That way we can look up
the stack traces that you generated. Thanks -

Also: is it only on this page that you get the crash you describe
above? Or can you crash like that on other Web pages, too?
Assignee: rogerl → Matti
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → imajes-qa
Note: I have an build from 10 days ago (20020617xx).
When I try the steps to reproduce, I see two errors in 
Tools > Web Development > JavaScript Console:

Error: aDocument.hasAttributeNS is not a function
Source File: chrome://navigator/content/pageInfo.js
Line: 539

Error: uncaught exception: [Exception... "'[JavaScript Error: 
"aDocument.hasAttributeNS is not a function" {file: 
"chrome://navigator/content/pageInfo.js" line: 539}]' when calling method: 
[nsIDOMNodeFilter::acceptNode]"  nsresult: "0x80570021 
(NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: 
chrome://navigator/content/pageInfo.js :: grabAllXLinks :: line 550"  data: yes]


However, I do not crash -
Keywords: crash
Attached file backtrace (deleted) — 
a 12 h. old CVS, Linux (non-debug, with symbols) seems to crash here:

#0  0x4009b92c in js_GetProperty () from /libmozjs.so
#1  0x4008eea2 in js_Interpret () from libmozjs.so
#2  0x40087f77 in js_Invoke () from libmozjs.so
#3  0x40595595 in nsXPCWrappedJSClass::CallMethod () from libxpconnect.so
#4  0x40591413 in nsXPCWrappedJS::CallMethod () from libxpconnect.so
#5  0x4018444e in PrepareAndDispatch () from libxpcom.so
#6  0x401844b2 in nsXPTCStubBase::Stub3 () from libxpcom.so
#7  0x40ed5e47 in nsTreeWalker::TestNode () from libgkcontent.so
#8  0x40ed5c8e in nsTreeWalker::ChildOf () from libgkcontent.so
#9  0x40ed54b2 in nsTreeWalker::FirstChildOf () from libgkcontent.so
#10 0x40ed5d31 in nsTreeWalker::ChildOf () from libgkcontent.so
#11 0x40ed54b2 in nsTreeWalker::FirstChildOf () from libgkcontent.so
with an official trunk linux 20020617xx i see the same as in comment 2
In addition, the "links" tab is blank
OS: Windows 98 → All
ha, i watch this match since the last 2 days and also the people in the german 
mozilla channel but i never clicked on PI :-)

confirming with my 10min old CVS optimized and 3days old debug build
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file win2k stack trace (deleted) — 
Phil : Do you know if this is Dom0 ?
Crashed for me, although it thought about it for a while. Win98SE build
2002062704-TRUNK.

Talkback ID #TB7786295G

Severity of this bug needs to be changed. "Normal" isn't used for browser crashes.
caillon means that this could be DOM Core
Assignee: Matti → jst
Severity: normal → critical
Component: Browser-General → DOM Core
QA Contact: imajes-qa → desale
Note: I looked up Talkback ID #TB7786295G (see Comment #7).

It has the same stack trace that Matti provided in Comment #6,
and R.K.Aa provided in Comment #3 -
i saved this page because it will possible disappear after the benchmark is
finished.

This doesn't crash if the java applet can't be loaded..
Summary: Mozilla crashes after clicking Page Info -> Tab "Links" → Mozilla crashes after clicking Page Info -> Tab "Links" [in js_GetProperty]
Installed Mozilla Trunk 2002062808 with Talkback enabled. 
The TB-ID is: TB7817395H. Maybe the stack gives a hint.
The error still occurs on that page, but i have been able to reproduce this on 
another page.
Created a testpage with an simple applet, Mozilla crashed again after PI->Links.
I used old applet-tag style, not the object-tag. Maybe that could be a reason,
but i did not look at the source at www.heise.de.



schnirbbel@gmx.de: thanks for providing a Talkback stack trace!
I looked up your Talkback ID TB7817395H. It shows the same stack trace
as those above, so that's good.

Thank you for testing the effect of Java applets on this problem.
If you have a reduced testcase, you can attach it to this bug
via the "Create a New Attachment" link above. That would be great -
I created a pure and simple html-testpage, it is online under:
http://www.meinebaustelle.de/applet/parameter.html
The applet itself doesn't do anything usefull, but it is enough for testing 
purpose. Inspected the source of heise, they use the old applet-tag as well 
(maybe for NS 4 User).
Hope, that is helpfull.
QA Contact: desale → stummala
js_GetProperty is a topcrash on the trunk.  Added topcrash to keywords and
modified summary for tracking.
Keywords: topcrash
Summary: Mozilla crashes after clicking Page Info -> Tab "Links" [in js_GetProperty] → Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty]
Doesn't crash with build 2002071008 - Win XP.

Weird ?!
Yes, somehow strange (arrgh, what the heck - cant use cursor-keys in this textfield 
to move back and forward, is this normal?)
The same build 2002071008 still crashes on my machine.
The URL is no longer valid since the chess benchmark is finished and there is no
applet.
adding NEW URL from the Reporter.
URL: http://www.heise.de/ct/schachduell/ → http://www.meinebaustelle.de/applet/p...
I think this crash is caused by an incorrect value being sent for JSProperty*. 
http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_JavaObject.c#804

Not sure what value should actually be sent here :-(
*** Bug 156757 has been marked as a duplicate of this bug. ***
OK.  Do we have a regression date?  I suspect this may be caused by the fix for
bug 59686...

The pageinfo code is trying to call getAttributeNS on the domnode, and I bet the
screwed-up proto chain interferes somehow...
Keywords: regression
Summary: Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] → Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] (only if java is installed)
*** Bug 157968 has been marked as a duplicate of this bug. ***
Attached patch workaround (obsolete) (deleted) — — Splinter Review 
this "fixes" the crash by not calling hasAttributeNS on applet elements. Since
it is a wallpaper fix i would say that we should only land this on the branch
and try to fix it appropriatly on the trunk
Comment on attachment 92302 [details] [diff] [review]
workaround

sr=jst, but please rename aDocument to aElement since we *know* we're not
dealing with a document here.
Attachment #92302 - Flags: superreview+
Comment on attachment 92302 [details] [diff] [review]
workaround

r=bzbarsky
Attachment #92302 - Flags: review+
->sicking to checkin
Assignee: jst → sicking
Comment on attachment 92302 [details] [diff] [review]
workaround

obsoleting, this one didn't make it to the branch
Attachment #92302 - Attachment is obsolete: true
dupping this to it's real problem

*** This bug has been marked as a duplicate of 59686 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment on attachment 92302 [details] [diff] [review]
workaround

trying for branch again...
Attachment #92302 - Attachment is obsolete: false
Marking adt1.0.1-.  Since this is branch only it'll be fixed in the next release.
Keywords: adt1.0.1 → adt1.0.1-
Comment on attachment 92302 [details] [diff] [review]
workaround

oki
Attachment #92302 - Attachment is obsolete: true
*** Bug 167356 has been marked as a duplicate of this bug. ***
Reopening and marking dependency so we can work around this for major releases
like 1.1 and 1.2 and so forth in the future (since bug 59686 is not likely to be
fixed any time soon).
Status: RESOLVED → REOPENED
Depends on: 59686
Resolution: DUPLICATE → ---
No longer depends on: 59686
Looks like there was a midair collision that removed the dependancy.....fixing.
Depends on: 59686
MacsBug stdlog from testcase in comment #13.
Somehow, my additional comments didn't get added to my attachment.  Been a while
since I posted here.

Anyway, Mozilla crashed very nicely on Mac OS 9.2.2 running on an iMac DV G3/400
with 192 MB RAM.  Build was trunk build 2002101508.  Need more info?  Feel free
to type.
Steps taken

1 Open the page http://www.meinebaustelle.de/applet/parameter.html and 
2 Select menu option "view page info 
3 Click the links button
4 Everything works as expected

The bug doesn't appear to be there on Linux build 20021214 and W2K build 1.3A 
All incidents in the database for this stack sig are from older builds.
Marking topcrash-.  Maybe this should be marked fixed?
Keywords: topcrash → topcrash-
no, afaik this still crashes
I was unable to reproduce this bug in the Nightly Build dated 2002.02.02,
running on Windows 2000.
WFM as well, xp pro sp1. Don't know what fixed this but the problem seems to be
solved in the recent nightlies.
This is still not fixed. The reason it doesn't crash is because a workaround was
landed. The underlying crash is still there.
 http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/pageInfo.js#568

The landing claims to be 1.0-branch-only but for whatever reason still lives on
the trunk. IMHO this wallpaper should be removed and a proper fix (for bug
59686) should be done.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
There has been a lot of work in the Page Info code recently.  CC'ing Daniel to
see if this one is safe to mark fixed or worksforme.
This bug is now WFM on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5)
Gecko/20041117 MultiZilla/1.8.0.1c

Should it be marked as such (as recommended in bug 195492#c67 )?
Isn't the wallpaper code still there to catch this? I.e. the bug is still there
but it has been worked around in the pageinfo code?
sicking: that's correct.

Raj Bhaskar, please read the entire bug carefully before commenting....
Blocks: 353557
No longer blocks: 353557
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
Is there a point to leaving this bug open? There was a crash, it was wallpapered, and there's another bug on fixing it the right way (comment 41). As long as bug 59686 exists why do we need this one too? (also the testcases linked from here are gone reducing the usefulness further).
Keywords: testcase-wanted
Whiteboard: [needs answer to comment 47 or should be closed][needs testcase]
I'm going to mark this fixed per comment 47 and the wall paper landing.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → FIXED
Crash Signature: [@ js_GetProperty]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: