Closed
Bug 422324
Opened 17 years ago
Closed 17 years ago
Crash on Java applets at processing.org [@ nsObjectFrame::CallSetWindow]
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 421833
People
(Reporter: fehe, Unassigned)
References
()
Details
(Keywords: crash, topcrash)
Crash Data
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031109 Minefield/3.0b5pre (like Firefox/2.0.0.13)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031109 Minefield/3.0b5pre
When running the java applets at the referenced URL, Firefox crashes. Sun JRE SE 6 Update 5.
Local Breakpad appears to be broken, because I submitted two crash reports a few minutes ago but all I can find is my old IDs for crashes from Feb 21 to 23. As such, I cannot provide Breakpad IDs.
Reproducible: Always
Steps to Reproduce:
1. Install JRE SE 6 Update 5, if you don't already have it installed
2. Make sure both JavaScript and Java are enabled then visit the referenced URL
3. Click the drop-down list (on the left) to select applets to run.
Firefox should crash on at least some of those. I tried the ones under Transform, but others probably also work.
Actual Results:
Firefox crashes.
Comment 1•17 years ago
|
||
wfm with Java 5 Update 6 and Firefox 3 Beta4.
Can you please try it again in the Firefox safemode : http://kb.mozillazine.org/Safe_Mode
Thanks for the feedback. Found the cause. If either Adblock Plus or NoScript (or both) is enabled, crashing occurs with the aforementioned URL.
I will endeavor to contact the extension authors to investigate whether this is a problem with their extensions or a problem with Firefox itself.
we'd still like a stack trace if at all possible, try:
http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg
Keywords: crash,
stackwanted
Comment 4•17 years ago
|
||
I was able to reproduce this crash, here is my breakpad URL: http://crash-stats.mozilla.com/report/index/ff101878-f059-11dc-9133-001a4bd43ef6. Giving a 404 for now but hopefully the digester will catch up.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ok; managed to get Breakpad IDs via a different profile. Here they are:
bp-7e56f794-eff3-11dc-bc74-001a4bd43ed6
bp-a3729d7d-f010-11dc-94b8-001a4bd43e5c
bp-f2935aeb-f010-11dc-a2c2-001a4bd43ef6
bp-fdf7ad1e-f010-11dc-a7d2-001a4bd43e5c
bp-fe76c4f0-f010-11dc-a661-001a4bd46e84
bp-05add6ab-f011-11dc-b780-001a4bd43e5c
bp-01eaff6b-f012-11dc-b249-001a4bd43ed6
bp-756d885e-f056-11dc-8a5a-001a4bd46e84
bp-8ff0e07d-f056-11dc-b9f2-001a4bd46e84
bp-d458effd-f056-11dc-8a88-001a4bd43ed6
bp-de5b62b5-f056-11dc-a2d1-001a4bd43ed6
Someone pointed me to Bug 409566. I will post my findings there. If someone
has reason to believe this should be marked a dupe of that bugs then go ahead.
A stack trace:
ChildEBP RetAddr
0012fe20 7c90e89a ntdll!KiFastSystemCallRet
0012fe24 7c81cd96 ntdll!ZwTerminateProcess+0xc
0012ff20 7c81cdee kernel32!_ExitProcess+0x62
0012ff34 6000179e kernel32!ExitProcess+0x14
0012ff40 60001b66 MOZCRT19!__crtExitProcess(int status = 1610619886)+0x2e [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\crt0dat.c @ 683]
0012ff78 60001bee MOZCRT19!doexit(int code = 0, int quick = 0, int retcaller = 0)+0x116 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\crt0dat.c @ 596]
0012ff88 00401439 MOZCRT19!exit(int code = 2088857559)+0xe [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\crt0dat.c @ 398]
0012ffc0 7c816fd7 firefox!__tmainCRTStartup(void)+0x169 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\memory\jemalloc\src\crtexe.c @ 605]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
Comment 7•17 years ago
|
||
I can reproduce (after changing applet several times, though) on a clean profile with just a NOP JS content policy ({shouldLoad:#1=(function () {return 1;}), shouldProcess:#1#}).
Judging by the stack, looks actually like a dupe of bug 409566
timeless, is it a dupe for you too?
BTW, are crashers like these automatically considered blockers for 1.9, or should we ask blocking status for that bug? I definitely want it fixed in Fx 3...
wrt windbg, you need to select [x] debug child processes also.
you have a couple of stacks, one is i believe a duplicate of bug 409566 comment 9.
Here is the other one:
Signature nsObjectFrame::CallSetWindow()
UUID fdf7ad1e-f010-11dc-a7d2-001a4bd43e5c
Time 2008-03-12 01:47:46-07:00
Uptime 0
Product Firefox
Version 3.0b5pre
Build ID 2008031109
OS Windows NT
OS Version 5.1.2600 Service Pack 2
CPU x86
CPU Info GenuineIntel family 6 model 8 stepping 6
Crash Reason EXCEPTION_ACCESS_VIOLATION
Crash Address 0x1
Comments
Crashing Thread
Frame Signature Source
0 nsObjectFrame::CallSetWindow() mozilla/layout/generic/nsObjectFrame.cpp:876
1 nsObjectFrame::Instantiate(char const*, nsIURI*) mozilla/layout/generic/nsObjectFrame.cpp:1650
2 nsObjectLoadingContent::Instantiate(nsIObjectFrame*, nsACString_internal const&, nsIURI*) mozilla/content/base/src/nsObjectLoadingContent.cpp:1635
3 nsObjectLoadingContent::EnsureInstantiation(nsIPluginInstance**) mozilla/content/base/src/nsObjectLoadingContent.cpp:724
4 nsHTMLPluginObjElementSH::GetPluginInstance(nsIXPConnectWrappedNative*, nsIPluginInstance**) mozilla/dom/src/base/nsDOMClassInfo.cpp:8815
5 nsHTMLPluginObjElementSH::NewResolve(nsIXPConnectWrappedNative*, JSContext*, JSObject*, long, unsigned int, JSObject**, int*) mozilla/dom/src/base/nsDOMClassInfo.cpp:9287
6 XPCWrapper::ResolveNativeProperty(JSContext*, JSObject*, JSObject*, XPCWrappedNative*, long, unsigned int, JSObject**, int) mozilla/js/src/xpconnect/src/XPCWrapper.cpp:438
7 XPC_NW_NewResolve mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp:641
8 js_LookupPropertyWithFlags mozilla/js/src/jsobj.c:3296
9 js_GetPropertyHelper mozilla/js/src/jsobj.c:3612
10 js_Interpret mozilla/js/src/jsinterp.c:4231
11 js_Invoke mozilla/js/src/jsinterp.c:1291
12 js_InternalInvoke mozilla/js/src/jsinterp.c:1347
13 JS_CallFunctionValue mozilla/js/src/jsapi.c:5024
14 nsJSContext::CallEventHandler(nsISupports*, void*, void*, nsIArray*, nsIVariant**) mozilla/dom/src/base/nsJSEnvironment.cpp:1961
15 nsGlobalWindow::RunTimeout(nsTimeout*) mozilla/dom/src/base/nsGlobalWindow.cpp:7739
16 nsGlobalWindow::TimerCallback(nsITimer*, void*) mozilla/dom/src/base/nsGlobalWindow.cpp:8070
17 nsTimerImpl::Fire() mozilla/xpcom/threads/nsTimerImpl.cpp:400
18 nsTimerEvent::Run() mozilla/xpcom/threads/nsTimerImpl.cpp:490
19 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:510
20 nsBaseAppShell::Run() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:151
21 PR_GetEnv
22 wmain mozilla/toolkit/xre/nsWindowsWMain.cpp:87
23 firefox.exe@0x217f
24 BaseProcessStart
Component: General → Plug-ins
Keywords: stackwanted
Product: Firefox → Core
QA Contact: general → plugins
Summary: Crash on Java applets at processing.org → Crash on Java applets at processing.org [@ nsObjectFrame::CallSetWindow]
(In reply to comment #8)
> wrt windbg, you need to select [x] debug child processes also.
>
I could not find that option on WinDbg 6.8.0004.0. Where do I find it?
Comment 10•17 years ago
|
||
Could be related to bug 418514 (adblock+ and java are crashing)
Comment 11•17 years ago
|
||
if you use file>open executable, it's in the dialog at the bottom.
if you're using attach to process, then i'd hope you don't reach this state (i just updated to 6.8 and the checkbox is definitely there).
| Reporter | ||
Comment 12•17 years ago
|
||
(In reply to comment #11)
> if you use file>open executable, it's in the dialog at the bottom.
>
Thanks. Finally got it. Here are two stack traces. Note: Both crashes occurred for different applets:
FIRST RUN
---------
(df4.4ec): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=6d4232a2 ebx=00000000 ecx=40000000 edx=00000000 esi=6d423279 edi=000340e8
eip=6d4232a4 esp=00033000 ebp=00034080 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\Java\jre1.6.0_05\bin\jpinscp.dll -
jpinscp+0x32a4:
6d4232a4 57 push edi
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00034080 7e418734 000401d2 0000000f 00000000 jpinscp+0x32a4
000340ac 7e418816 6d423279 000401d2 0000000f USER32!InternalCallWinProc+0x28
00034114 7e41c63f 00000000 6d423279 000401d2 USER32!UserCallWinProcCheckWow+0x150
00034144 7e41f65d 6d423279 000401d2 0000000f USER32!CallWindowProcAorW+0x98
00034164 6d42374e 6d423279 000401d2 0000000f USER32!CallWindowProcA+0x1b
00035204 7e418734 000401d2 0000000f 00000000 jpinscp+0x374e
00035230 7e418816 6d423279 000401d2 0000000f USER32!InternalCallWinProc+0x28
00035298 7e41c63f 00000000 6d423279 000401d2 USER32!UserCallWinProcCheckWow+0x150
000352c8 7e41f65d 6d423279 000401d2 0000000f USER32!CallWindowProcAorW+0x98
000352e8 6d42374e 6d423279 000401d2 0000000f USER32!CallWindowProcA+0x1b
00036388 7e418734 000401d2 0000000f 00000000 jpinscp+0x374e
000363b4 7e418816 6d423279 000401d2 0000000f USER32!InternalCallWinProc+0x28
0003641c 7e41c63f 00000000 6d423279 000401d2 USER32!UserCallWinProcCheckWow+0x150
0003644c 7e41f65d 6d423279 000401d2 0000000f USER32!CallWindowProcAorW+0x98
0003646c 6d42374e 6d423279 000401d2 0000000f USER32!CallWindowProcA+0x1b
0003750c 7e418734 000401d2 0000000f 00000000 jpinscp+0x374e
00037538 7e418816 6d423279 000401d2 0000000f USER32!InternalCallWinProc+0x28
000375a0 7e41c63f 00000000 6d423279 000401d2 USER32!UserCallWinProcCheckWow+0x150
000375d0 7e41f65d 6d423279 000401d2 0000000f USER32!CallWindowProcAorW+0x98
000375f0 6d42374e 6d423279 000401d2 0000000f USER32!CallWindowProcA+0x1b
SECOND RUN
----------
(9d0.ce8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00006b08 ebx=00006b06 ecx=209909b8 edx=00b73e99 esi=00fe0000 edi=00d2d892
eip=05425664 esp=085ff6b0 ebp=085ff708 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
05425664 850500014802 test dword ptr ds:[2480100h],eax ds:0023:02480100=????????
0:025> kb
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
085ff708 05442ec6 0000008d 4243c50a bef4dd6d 0x5425664
085ff778 054334ae 3f6c5a59 434709f4 4301c83c 0x5442ec6
085ff838 0542d1a3 00000002 00000003 3ec6630f 0x54334ae
085ff928 05445ece 26c1f18d 085ff958 085ff980 0x542d1a3
085ff948 05302c7a c0800000 41000000 05302c87 0x5445ece
085ff980 05302c87 209be9e8 085ff98c 26bced39 0x5302c7a
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\PROGRA~1\Java\JRE16~2.0_0\bin\client\jvm.dll -
085ffaa0 6d88b99c 00001f80 085ffbd0 073e4400 0x5302c87
085ffab8 6d88bd2d 085ffb14 085ffc8c 0000000a jvm!AsyncGetCallTrace+0x2d2cc
085ffb30 6d913441 085ffc84 085ffb00 085ffbd0 jvm!AsyncGetCallTrace+0x2d65d
085ffca8 6d966792 073e4400 073e4400 073e4400 jvm!JVM_FindSignal+0x502f1
085ffcd0 6d9130ac 7c926abe 085ffd10 7c96cde9 jvm!JVM_FindSignal+0xa3642
085ffcd4 7c926abe 085ffd10 7c96cde9 02430000 jvm!JVM_FindSignal+0x4ff5c
6d9130ac ebffffff ec458b17 f2b2e850 8bc3ffff ntdll!RtlFreeHeapSlowly+0x5c2
6d9130ac 00000000 ec458b17 f2b2e850 8bc3ffff 0xebffffff
Comment 13•17 years ago
|
||
your first stack matches bug 409566, your second stack doesn't match any of the other stacks we have. wonderful.
i think the thing to do is to file a new bug for your second stack, and then file a bug report w/ sun w/ the same stack including the url (i hope you have) of the crash (include that in the url for the bug report you file w/ us too) and the url to our bug report. then update our report w/ the sun bug report url. and finally comment here w/ the bug number for that stack.
| Reporter | ||
Comment 14•17 years ago
|
||
(In reply to comment #13)
> i think the thing to do is to file a new bug for your second stack, and then
> file a bug report w/ sun w/ the same stack including the url (i hope you have)
> of the crash (include that in the url for the bug report you file w/ us too)
> and the url to our bug report. then update our report w/ the sun bug report
> url. and finally comment here w/ the bug number for that stack.
>
I've just filed Bug 422751 plus a bug report with Sun. If Sun assigns me a bug number, I will update that bug with it.
Comment 15•17 years ago
|
||
Looks like I cannot reproduce this anymore with Java Plugin 1.6.0_10 beta (new Plugin architecture may have helped here).
Same trunk build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040404 Minefield/3.0pre eMusic DLM/4.0_1.0.0.1)
1.6 Update 5 stable crashes, 1.6 Update 10 doesn't.
Fixed on Sun side?
Component: Plug-ins → Build Config
Comment 16•17 years ago
|
||
Please do not change the component to "build config"
Component: Build Config → Plug-ins
Comment 17•17 years ago
|
||
Matthias, did I?
If so, it's been unintentional (I don't recall to have touched the component drop-down).
Comment 18•17 years ago
|
||
This should've been fixed by the fix for bug 421833 (dupe). Marking duplicate.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
| Assignee | ||
Updated•14 years ago
|
Crash Signature: [@ nsObjectFrame::CallSetWindow]
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•