Closed Bug 76677 Opened 23 years ago Closed 23 years ago

Crash: Tasks>Tools>Java Console crashes browser

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: junruh, Assigned: edburns)

References

Details

(Keywords: crash, Whiteboard: [oji_working] important to mozilla0.9?)

Attachments

(2 files)

diff -u of fix for this bug, first iteration
382 bytes, patch
Details | Diff | Splinter Review
Don't use NS_ASSERT, test and return nsnull instead.
819 bytes, patch
Details | Diff | Splinter Review 
WinNT Netscape 6 build 2001041904
29331348
Talkback ID 29331348
Keywords: crash
i see it..there are a number of crashers on OJI recently. one more!
Severity: normal → critical
I see this in last night's trunk build.  Yikes.

Ed
Status: NEW → ASSIGNED
Whiteboard: [oji_working]
Here's the stack trace.  It's crashing in the java plugin.

JPINS32! 6d2eaf87()
JPINS32! 6d2eb412()
JPINS32! 6d2e319b()
nsJVMManager::ShowJavaConsole(nsJVMManager * const 0x01691ac0) line 158
XPTC_InvokeByIndex(nsISupports * 0x01691ac0, unsigned int 5, unsigned int 0, 
nsXPTCVariant * 0x0012d890) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x027be520, 
nsXPCWrappedNative * 0x0441f7b0, const XPCNativeMemberDescriptor * 0x0441fddc, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 
0x028d9450, long * 0x0012da78) line 934 + 42 bytes
WrappedNative_CallMethod(JSContext * 0x027be520, JSObject * 0x02821d28, 
unsigned int 0, long * 0x028d9450, long * 0x0012da78) line 250 + 34 bytes
js_Invoke(JSContext * 0x027be520, unsigned int 0, unsigned int 0) line 813 + 23 
bytes
js_Interpret(JSContext * 0x027be520, long * 0x0012e7f8) line 2706 + 15 bytes
js_Invoke(JSContext * 0x027be520, unsigned int 1, unsigned int 2) line 830 + 13 
bytes
js_InternalInvoke(JSContext * 0x027be520, JSObject * 0x028a6108, long 42623280, 
unsigned int 0, unsigned int 1, long * 0x0012e990, long * 0x0012e920) line 902 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x027be520, JSObject * 0x028a6108, long 
42623280, unsigned int 1, long * 0x0012e990, long * 0x0012e920) line 3334 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x027be6d0, void * 
0x028a6108, void * 0x028a6130, unsigned int 1, void * 0x0012e990, int * 
0x0012e98c, int 0) line 940 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x05ac3094) line 154 + 64 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x044068e0, 
nsIDOMEvent * 0x05ac3094, nsIDOMEventTarget * 0x04421868, unsigned int 8, 
unsigned int 7) line 1033 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x03263db0, nsEvent * 
0x0012f3cc, nsIDOMEvent * * 0x0012f278, nsIDOMEventTarget * 0x04421868, 
unsigned int 7, nsEventStatus * 0x0012f418) line 1953 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x04421860, nsIPresContext * 
0x03263db0, nsEvent * 0x0012f3cc, nsIDOMEvent * * 0x0012f278, unsigned int 1, 
nsEventStatus * 0x0012f418) line 3673
PresShell::HandleDOMEventWithTarget(PresShell * const 0x03264d50, nsIContent * 
0x04421860, nsEvent * 0x0012f3cc, nsEventStatus * 0x0012f418) line 5452 + 39 
bytes
nsMenuFrame::Execute() line 1422
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x028c2040, nsIPresContext * 
0x03263db0, nsGUIEvent * 0x0012f840, nsEventStatus * 0x0012f734) line 399
PresShell::HandleEventInternal(nsEvent * 0x0012f840, nsIView * 0x05ac26a0, 
unsigned int 1, nsEventStatus * 0x0012f734) line 5420 + 41 bytes
PresShell::HandleEvent(PresShell * const 0x03264d54, nsIView * 0x05ac26a0, 
nsGUIEvent * 0x0012f840, nsEventStatus * 0x0012f734, int 0, int & 1) line 5332 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x05ac26a0, nsGUIEvent * 0x0012f840, 
unsigned int 8, nsEventStatus * 0x0012f734, int 0, int & 1) line 377
nsView::HandleEvent(nsView * const 0x056216b0, nsGUIEvent * 0x0012f840, 
unsigned int 8, nsEventStatus * 0x0012f734, int 0, int & 1) line 350
nsView::HandleEvent(nsView * const 0x05abc130, nsGUIEvent * 0x0012f840, 
unsigned int 8, nsEventStatus * 0x0012f734, int 0, int & 1) line 350
nsView::HandleEvent(nsView * const 0x032635b0, nsGUIEvent * 0x0012f840, 
unsigned int 28, nsEventStatus * 0x0012f734, int 1, int & 1) line 350
nsViewManager::DispatchEvent(nsViewManager * const 0x03263750, nsGUIEvent * 
0x0012f840, nsEventStatus * 0x0012f734) line 2039
HandleEvent(nsGUIEvent * 0x0012f840) line 68
nsWindow::DispatchEvent(nsWindow * const 0x05a84124, nsGUIEvent * 0x0012f840, 
nsEventStatus & nsEventStatus_eIgnore) line 704 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f840) line 725
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4028 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4273
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 2818161, long * 
0x0012fc10) line 3009 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x000e03a4, unsigned int 514, unsigned int 0, 
long 2818161) line 959 + 27 bytes
USER32! 77e71268()
002b0071()

Patrick, any chance this was brought on by your fix to 26516?

Ed
It turns out the reason this is crashing is an assertion in the java plugin.

For some reason, the JNIEnv is null when it gets to the PLugin:

VMClearException(JNIEnv_ * 0x00000000) line 251 + 9 bytes
JVMShowConsole(JNIEnv_ * 0x00000000, int 1) line 543 + 8 bytes
CJavaConsole::Show(CJavaConsole * const 0x009118c0) line 165 + 21 bytes
JVM_ShowConsole() line 159
nsJVMManager::ShowJavaConsole(nsJVMManager * const 0x01691b00) line 158
XPTC_InvokeByIndex(nsISupports * 0x01691b00, unsigned int 5, unsigned int 0, 
nsXPTCVariant * 0x0012d890) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x0280e520, 
nsXPCWrappedNative * 0x04170940, const XPCNativeMemberDescriptor * 0x04170cac, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 
0x02909d58, long * 0x0012da78) line 934 + 42 bytes
WrappedNative_CallMethod(JSContext * 0x0280e520, JSObject * 0x00eedd28, 
unsigned int 0, long * 0x02909d58, long * 0x0012da78) line 250 + 34 bytes
js_Invoke(JSContext * 0x0280e520, unsigned int 0, unsigned int 0) line 813 + 23 
bytes
js_Interpret(JSContext * 0x0280e520, long * 0x0012e7f8) line 2706 + 15 bytes

This is why I think Beard's 26516 fix is involved.
I'm using a Linux build that I pulled yesterday, using the Java plugin that comes 
with NS6.01, and I'm not seeing any problems showing the Java console (it just 
takes a while to load, as expected). Are you using the release version of the 
Java plugin?

Adding David Price, to see if he can reproduce this crash.

Reporter, can you please try visiting a page with an applet first, seeing that 
the applets load, then try opening the java console
If I visit a page with an applet, THEN load the java console, it works.

Beard, with this information, do you have any clue where I should look on this?

Ed
I also can be reproduced with the trunk. 
Here's why this is happening.  The JNIEnv is null because the VM isn't
started.

modules\oji\src\nsJVMManager.cpp: 

NS_METHOD
nsJVMManager::ShowJavaConsole(void)
{
    JVM_ShowConsole();
    return NS_OK;
}

calls:

ladybird\ext\plugin\oji-plugin\src\win32\core\CJavaConsole.cpp

NS_IMETHODIMP CJavaConsole::Show(void) 
{
    TRACE("CJavaConsole::Show\n");

    JVMShowConsole(m_pIJavaVM->GetJNIEnv(), TRUE);

    return NS_OK;
}

GetJNIEnv():

ladybird\ext\plugin\jpishare\src\win32\CJavaVMService.cpp

NIEnv* CJavaVMService::GetJNIEnv()
{
    ATLTRACE("CJavaVMService::GetJNIEnv\n");

    ::EnterCriticalSection(&m_csJavaVMService);

    JNIEnv* env = NULL;

    if (m_jni.IsJavaStarted())
	env = m_jni.GetJNIEnv();
    else
	env = NULL;

    ::LeaveCriticalSection(&m_csJavaVMService);

    return env;
}

and IsJavaStarted returns false.  Whoomp there it is.

Since the Unix java plugin is a mostly different source base, this may
be accounted for in the Unix side.

Workaround forthcoming.
It looks like tho OJI module thinks the JVM is running, but really it
isn't.

After Beard's patch to 26516, the win32 java plugin is started here,
when an applet page is visited.

CJavaJNI::Initialize() line 93
CActivatorJNI::Initialize() line 76 + 14 bytes
CJavaVMService::Initialize() line 71 + 19 bytes
CJavaPluginApp::StartJVM() line 950 + 15 bytes
CJavaPluginFactory::CreateInstance() line 360 + 10 bytes
nsPluginHostImpl::SetUpPluginInstance() line 2879 + 46 bytes
nsPluginHostImpl::InstantiateEmbededPlugin() line 2552 + 24 bytes
nsObjectFrame::InstantiatePlugin() line 1064

However, the OJI module's awareness of the running state of the JVM is
set to nsJVMStatus_Running long *before* CJavaJNI::Initialize() is
called, in fact, on startup.

nsJVMManager::StartupJVM() line 630
nsJVMManager::MaybeStartupLiveConnect() line 781 + 20 bytes
nsJVMManager::StartupLiveConnect() line 128 + 11 bytes
nsJSEnvironment::nsJSEnvironment() line 1505 + 49 bytes
nsJSEnvironment::GetScriptingEnvironment() line 1446 + 27 bytes
NS_CreateScriptContext() line 1545 + 5 bytes
nsDocShell::EnsureScriptEnvironment() line 4462 + 50 bytes
nsWebShell::GetInterface() line 329 + 19 bytes
nsGetInterface::operator()() line 37 + 31 bytes
nsCOMPtr<nsIDOMWindowInternal>::assign_from_helper() line 970 + 18 bytes
nsCOMPtr<nsIDOMWindowInternal>::nsCOMPtr<nsIDOMWindowInternal>() line 552
nsAppShellService::GetHiddenWindowAndJSContext() line 713 + 32 bytes
nsAppShellService::SetXPConnectSafeContext() line 177 + 40 bytes
nsAppShellService::CreateHiddenWindow() line 248
main1() line 988
main() line 1300 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba3c()

nsJVMStatus
nsJVMManager::StartupJVM(void)
{
//...

    // beard: do we really need an explicit startup mechanim for the JVM?
    // since we obtained a working JVM plugin, assume it is running.
    fStatus = nsJVMStatus_Running;

//...
    return fStatus;
}

I think the right way to fix this is to remove nsJSEnvironment's
construction time dependency on nsJVMManager::StartupLiveConnect(), and
remove Beard's assumption in nsJVMManager::StartupJVM(), so that
StartupJVM actually starts up the JVM.  What do ya'll think?


I propose we add a call to JVM_GetJNIEnv() to GetConsole(), to ensure that Java 
has truly started up. For some reason, in the distant past, warren elected to 
remove the explicit StartupJVM()/ShutdownJVM() methods from nsIJVMPlugin (methods 
which the MRJ plugin still implements btw). 

Patrick, I concurr with your analysis.  Unfortunately, my organization's socks 
gateway is down at the moment, I can't even produce a cvs diff.  I'm attaching 
my local file diff, so we can get approval.  As oji module owner, I give 
ra=edburns.  Patrick, could you give r=beard?


Sorry, but PR_ASSERT() is a debug build-only thing, thus the call to 
JVM_GetJVNIEnv() won't happen in non-DEBUG builds. Generating a better diff.

r=beard

putting on 0.9 radar.
Target Milestone: --- → mozilla0.9
sr=brendan@mozilla.org.

Nominating for 0.9.

/be
Keywords: mozilla0.9
Whiteboard: [oji_working] → [oji_working] important to mozilla0.9?
a= asa@mozilla.org for checkin to 0.9
Patch checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Hey!  I saw that "[oji_working] important to mozilla0.9?" status.  If I knew how 
to make a stern, frowny emoticon, I'd be doing it right now.

Wow, whattabug.
(I was kidding about the last comment; hope y'all took it in the spirit it was 
meant)
*** Bug 76839 has been marked as a duplicate of this bug. ***
verifd fixed on 0424 build on win. No crash after opening java console
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

Creator:
Created:
Updated:
Size: