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)

x86
All
defect

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.
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
I am not using any Java plugin. None installed. The attachment is in a gzip format, I believe. Yes. Reattaching as plain text.
Thanks, I'll look at this tomorrow.
Updated QA contact and added avm to CC list
QA Contact: rpallath → raghu
This still happens, I am afraid.
p1 crasher.
Priority: -- → P1
Still happening.
Whiteboard: [oji_working]
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
Wah? That stack crawl doesn't look like any sort of LiveConnect interaction. Did you paste in the correct one?
Severity: normal → critical
Keywords: crash
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?).
i crashed on w2k buildid 2001091508 talkback id: TB35451960Q letting you know, despite the present traces
Correction. It doesn't crash when Java is installed/enabled. That just seems like a random occurance.
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
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
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
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.
Attinasi, waterson, this crash is due to GetPrimaryFrameFor() handing back a bogus frame (i.e. deleted frame), are there known bugs on such problems?
Attinasi, waterson, please see my above comment.
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.
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.
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
Attached file Stack trace of crash under Windows (deleted) —
That stack looks a bit different than the one I get on Win2k, but the problem is the same, bad frame pointer (null vtable).
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.
I can't reproduce this anymore, using 2001122906 build. Marking resolved?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified on all platforms (2002-01-01-08-trunk) with jre 1.3.1 without crashing.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: