Closed
Bug 69835
Opened 24 years ago
Closed 23 years ago
Mozilla crashes when Java is disabled when entering the attached URL
Categories
(Core Graveyard :: Java: OJI, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: petter.sundlof, Assigned: jst)
References
()
Details
(Keywords: crash, Whiteboard: [oji_working])
Attachments
(6 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1 i686; en-US; Galeon) Gecko/20010220
BuildID: 20010220
Have Java disabled in preferences, and load http://www.elephant-talk.com, and
you will experience a crash (segfault).
Enable it (even though you don't any plug-in installed -- you'll just get the
GTK+ dialogue, saying there's not Java installed) and Mozilla won't crash.
(P.S. I just took a very, very wild guess for the Component. D.S.)
Reproducible: Always
Steps to Reproduce:
1) Disabled Java in preferences
2) Go to the URL http://www.elephant-talk.com
Actual Results: Mozilla crashes
Expected Results: Mozilla should successfully render the page.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Changing component and QA contact
Component: Java APIs to WebShell → OJI
QA Contact: geetha.vaidyanaathan → rpallath
What is the file type of your stack trace attachment? Can you please attach
the stack trace as text?
I do see the problem, but please note that you can't mix a debug build of
mozilla with the non-debug java plugin. Have you tried with a --disable-debug
build?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 4•24 years ago
|
||
I am not using any Java plugin. None installed.
The attachment is in a gzip format, I believe.
Yes. Reattaching as plain text.
Reporter | ||
Comment 5•24 years ago
|
||
Updated QA contact and added avm to CC list
QA Contact: rpallath → raghu
Reporter | ||
Comment 8•24 years ago
|
||
This still happens, I am afraid.
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
Patrick,
The top of the stack trace shows some liveconnect interaction. Can you give me
some insight as to why this is crashing if java is disabled in the prefs? This
might be a dup of an existing bug you and Xiaobin are working on:
#0 0x41357eb6 in nsGenericHTMLElement::GetPrimaryFrame (aContent=0x86ca8d0,
aFormControlFrame=@0xbfffdf14, aFlushNotifications=1)
at nsGenericHTMLElement.cpp:2554
#1 0x4137b3c1 in nsHTMLInputElement::SetValue (this=0x86ca8d0,
aValue=@0x85a5b50) at nsHTMLInputElement.cpp:497
#2 0x401553b4 in XPTC_InvokeByIndex (that=0x86ca8fc, methodIndex=88,
paramCount=1, params=0xbfffe1e0) at xptcinvoke_unixish_x86.cpp:138
#3 0x408cc348 in XPCWrappedNative::CallMethod (ccx=@0xbfffe2f0,
mode=CALL_SETTER) at xpcwrappednative.cpp:1835
#4 0x408e64b5 in XPCWrappedNative::SetAttribute (ccx=@0x41670908)
at xpcprivate.h:1730
#5 0x408d4986 in XPC_WN_GetterSetter (cx=0x84ba7d8, obj=0x8666fc0, argc=1,
argv=0x8788e18, vp=0xbfffe4b0) at xpcwrappednativejsops.cpp:1265
#6 0x402066b6 in js_Invoke (cx=0x84ba7d8, argc=1, flags=2) at jsinterp.c:807
#7 0x40206a96 in js_InternalInvoke (cx=0x84ba7d8, obj=0x8666fc0,
fval=140931032, flags=0, argc=1, argv=0xbfffebb4, rval=0xbfffebb4)
at jsinterp.c:896
#8 0x40227c84 in js_SetProperty (cx=0x84ba7d8, obj=0x8666fc0, id=136119208,
vp=0xbfffebb4) at jsobj.c:2554
#9 0x402126e5 in js_Interpret (cx=0x84ba7d8, result=0xbfffedd0)
at jsinterp.c:2546
#10 0x40206e78 in js_Execute (cx=0x84ba7d8, chain=0x84acdb8, script=0x8429028,
down=0x0, special=0, result=0xbfffedd0) at jsinterp.c:986
---Type <return> to continue, or q <return> to quit---
#11 0x401da5e0 in JS_EvaluateUCScriptForPrincipals (cx=0x84ba7d8,
obj=0x84acdb8, principals=0x86d19b8, chars=0xbfffefb8, length=8,
filename=0x877bf00 "http://www.elephant-talk.com/cgi-bin/marquee.pl",
lineno=101, rval=0xbfffedd0) at jsapi.c:3273
If this isn't in liveconnect, please re-assign back to me or elsewhere as
appropriate.
Assignee: edburns → beard
Status: ASSIGNED → NEW
Comment 13•23 years ago
|
||
Wah? That stack crawl doesn't look like any sort of LiveConnect interaction. Did
you paste in the correct one?
Reporter | ||
Comment 14•23 years ago
|
||
This is persisting. It has mutated now, also -- it crashes even when Java is
installed and enabled (how about modifying the Summary etc of this bug?).
Comment 15•23 years ago
|
||
i crashed on w2k buildid 2001091508
talkback id: TB35451960Q
letting you know, despite the present traces
Reporter | ||
Comment 16•23 years ago
|
||
Correction. It doesn't crash when Java is installed/enabled. That just seems
like a random occurance.
Comment 17•23 years ago
|
||
This bug happens consistently in Windows platform. And the stack trace is
exactly as Ed's post on 6/06. However, I won't think it is a liveconnect issue.
I do think it is a problem of interaction between the layout render and
javascript engine.
Change QA contact to pmac@netscape.com.
Assignee: beard → xiaobin.lu
OS: Linux → All
QA Contact: raghu → pmac
Comment 18•23 years ago
|
||
Based on the stack trace Ed posted on 6/06, it crashes with invalid access to
frame object. So if java is not enabled, the browser should not bother with
nsObjectFrame and it should set frame to null in order to avoid the invalid
access.
I would like to reassign this bug to XPConnect module based on the stack trace.
Assignee: xiaobin.lu → dbradley
Comment 19•23 years ago
|
||
I can't see that xpconnect is doing anything wrong here. It knows nothing about
java or frames. It is just routing a call. I think the more interesting thing is
deeper in the stack (not the top part that edburns repeated inline)... This is
in response to a GlobalWindowImpl::RunTimeout.
jst, look familiar? a dup maybe? can you help? or reassign this bug
appropriately?
Assignee: dbradley → jst
Comment 20•23 years ago
|
||
I am also can reproduce it on both Solaris and Linux.
But while on Solaris i am getting exactly same stacktrace as Ed
on Linux (RedHat 6.2) situation is different - mozilla crashes because it
null thread gets executed. Here is the list of threads:
* 6 Thread 4101 (runnable) 0x0 in ?? ()
5 Thread 3076 (runnable) 0x40594deb in __sigsuspend (set=0xbf3ffb7c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
4 Thread 2051 (runnable) 0x40594deb in __sigsuspend (set=0xbf5ffc0c)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
3 Thread 1026 (runnable) 0x40621f50 in __poll (fds=0xbf7ffcb8, nfds=1,
timeout=29335) at ../sysdeps/unix/sysv/linux/poll.c:45
2 Thread 2049 (runnable) 0x40621f50 in __poll (fds=0x812e504, nfds=1,
timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:45
1 Thread 1024 (runnable) 0x4025502a in nsXPTMethodInfo::GetParamCount (
this=0x8252c00) at ../../../../../../dist/include/xptinfo.h:204
I did some investigation and it looks like that 4101
thread was getting chrome jar
and sucessfully finished.
Up to now i did not realize why it get on CPU again ...
I will attach mozilla output to illustrate observed behavior.
Comment 21•23 years ago
|
||
Assignee | ||
Comment 22•23 years ago
|
||
Assignee | ||
Comment 23•23 years ago
|
||
Attinasi, waterson, this crash is due to GetPrimaryFrameFor() handing back a
bogus frame (i.e. deleted frame), are there known bugs on such problems?
Assignee | ||
Comment 24•23 years ago
|
||
Attinasi, waterson, please see my above comment.
Comment 25•23 years ago
|
||
I think there may be related bugs, certainly there are other cases where a stale
frame is not purged from the frame map or a frame list. I'll look at what is
happening with the ObjectFrame and make sure that we don't forget about it after
we decide not to use one - or something. Reassign to me if that is the last part
of the bug, please.
Assignee | ||
Comment 26•23 years ago
|
||
Mark, it looks like the frame we're getting the frame for an input element here,
not an object element, and that's where we're crasing. I don't see how the crash
in input element code could be related to Java being disabled, but it seems as
if it is. http://bugzilla.mozilla.org/attachment.cgi?id=37423&action=view shows
the stack where we crash.
Comment 27•23 years ago
|
||
FWIW I get a slightly different stack trace but I think similar. I thought I'd
pass it along in case it sparks some inspiration.
frame->GetStyleData(eStyleStruct_Display, (const nsStyleStruct*&)display);
frame's vtable is null and thus causes the access violation in this case.
I'm seeing pretty much the same behavior under Windows. If Java is enabled all
is well, if not boom.
Stack trace to follow
Comment 28•23 years ago
|
||
Assignee | ||
Comment 29•23 years ago
|
||
That stack looks a bit different than the one I get on Win2k, but the problem is
the same, bad frame pointer (null vtable).
Comment 30•23 years ago
|
||
I found that I get the original stack trace when it bombs at the beginning of
the rendering of the window. I get my stack trace when it bombs near the end. I
also regularly get my stack trace but only occasionally get the original one.
Reporter | ||
Comment 31•23 years ago
|
||
I can't reproduce this anymore, using 2001122906 build.
Marking resolved?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 32•23 years ago
|
||
verified on all platforms (2002-01-01-08-trunk) with jre 1.3.1
without crashing.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•