Page 1 of 1

JVM Crash with swing Application

PostPosted: Thu Feb 21, 2019 8:52 am
by timobusch
Sometimes we suffer a JVM Crash when running our Swing application which uses jcef.

The JVM crash only appears on Windows 7 . On Windows 10 the JVM does not crash with this application.
As you can see below in the event viewer output the crash happended on a access to libcef.dll

Now I wanted to ask how can I get more information about the reason of the error. Are there possibilities to get more information and how can this be done?
Is it possible to get some kind of stacktrace so we know which module or method causes the crash?
Are there known issues regarding Windows 7 and JVM crashes and possibly workarounds?

After a crash I found the following in the windows event viewer:

Protokollname: Application
Quelle: Application Error
Datum: 18.02.2019 14:36:05
Ereignis-ID: 1000
Aufgabenkategorie:(100)
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: PC151544.swr.ard
Beschreibung:
Name der fehlerhaften Anwendung: java.exe, Version: 8.0.192.12, Zeitstempel: 0x5bdc55ef
Name des fehlerhaften Moduls: libcef.dll, Version: 3.3538.1852.0, Zeitstempel: 0x5be3c2d0
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000001e1a393
ID des fehlerhaften Prozesses: 0x2d98
Startzeit der fehlerhaften Anwendung: 0x01d4c78eabc8da74
Pfad der fehlerhaften Anwendung: D:\cs\tmp\_9.x\openjdk-8u192-b12-jre-64\bin\java.exe
Pfad des fehlerhaften Moduls: D:\cs\tmp\_9.x\erfassung-clt-9.7\bin\jcef\win64\libcef.dll
Berichtskennung: 238c3704-3382-11e9-9146-c85b76081a48
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2019-02-18T13:36:05.000000000Z" />
<EventRecordID>102732</EventRecordID>
<Channel>Application</Channel>
<Computer>PC151544.swr.ard</Computer>
<Security />
</System>
<EventData>
<Data>java.exe</Data>
<Data>8.0.192.12</Data>
<Data>5bdc55ef</Data>
<Data>libcef.dll</Data>
<Data>3.3538.1852.0</Data>
<Data>5be3c2d0</Data>
<Data>c0000005</Data>
<Data>0000000001e1a393</Data>
<Data>2d98</Data>
<Data>01d4c78eabc8da74</Data>
<Data>D:\cs\tmp\_9.x\openjdk-8u192-b12-jre-64\bin\java.exe</Data>
<Data>D:\cs\tmp\_9.x\erfassung-clt-9.7\bin\jcef\win64\libcef.dll</Data>
<Data>238c3704-3382-11e9-9146-c85b76081a48</Data>
</EventData>
</Event>

Re: JVM Crash with swing Application

PostPosted: Thu Feb 21, 2019 4:29 pm
by magreenblatt
At a minimum you need to provide reproduction steps using a JCEF sample application or a symbolized crash stack trace.

Re: JVM Crash with swing Application

PostPosted: Fri Feb 22, 2019 2:56 am
by timobusch
How can I get a symbolized crash stack trace?

Re: JVM Crash with swing Application

PostPosted: Fri Feb 22, 2019 10:39 am
by magreenblatt
Download "Debug Symbols" for the correct CEF version from http://opensource.spotify.com/cefbuilds/index.html. Extract the PDB file next to libcef.dll. Run the Java application then use Visual Studio to attach to the java.exe process. Perform the steps that cause the crash and you should get a symbolized stack trace in the debug window.

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 5:48 am
by HarmfulBreeze
Hey, so I have the exact same issue and I wanted to debug it since sometimes my app crashes during the N_Shutdown() call and sometimes it does not.
I'm running the latest JCEF with CEF v78.2.7. Here is what I have, when using the natives built with the Debug configuration for Win64:

Code: Select all
initialize on Thread[AWT-EventQueue-0,6,main] with library path C:\Users\piorr\IdeaProjects\overlay\libs\lib\win64
[0217/110831.813:INFO:content_main_runner_impl.cc(959)] Chrome is running in full browser mode.
[0217/110831.833:ERROR:viz_process_transport_factory.cc(302)] Switching to software compositing.

<we call the dispose function on CefApp>

shutdown on Thread[AWT-EventQueue-0,6,main]
[0217/110834.299:WARNING:discardable_shared_memory_manager.cc(432)] Some MojoDiscardableSharedMemoryManagerImpls are still alive. They will be leaked.
[0217/110834.306:FATAL:memory_dump_manager.cc(247)] Check failed: (*mdp_iter)->task_runner && (*mdp_iter)->task_runner->RunsTasksInCurrentSequence(). MemoryDumpProvider "DiscardableSharedMemoryManager" attempted to unregister itself in a racy way. Please file a crbug.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (os_windows_x86.cpp:144), pid=25340, tid=0x0000000000002f64
#  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
#
# JRE version: Java(TM) SE Runtime Environment (8.0_172-b11) (build 1.8.0_172-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.172-b11 mixed mode windows-amd64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\piorr\IdeaProjects\overlay\hs_err_pid25340.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
[0217/110834.324:FATAL:context.cc(58)] Check failed: !g_context. CefShutdown was not called

[error occurred during error reporting , id 0xe0000000]

I attached the Java dump to my post.
The other weird thing I noticed is that I am not getting a 0xC0000005 with the Debug build, but a 0xC000001D instead.

Here is the call stack from my VS Debugging:
Code: Select all
    libcef.dll!discardable_memory::DiscardableSharedMemoryManager::~DiscardableSharedMemoryManager() Line 249   C++
>   libcef.dll!content::ContentMainRunnerImpl::~ContentMainRunnerImpl() Line 608   C++
    [Inline Frame] libcef.dll!std::__1::default_delete<content::ContentMainRunnerImpl>::operator()(content::ContentMainRunnerImpl * __ptr) Line 2338   C++
    [Inline Frame] libcef.dll!std::__1::unique_ptr<content::ContentMainRunnerImpl,std::__1::default_delete<content::ContentMainRunnerImpl> >::reset(content::ContentMainRunnerImpl * __p) Line 2651   C++
    [Inline Frame] libcef.dll!std::__1::unique_ptr<content::ContentMainRunnerImpl,std::__1::default_delete<content::ContentMainRunnerImpl> >::~unique_ptr() Line 2605   C++
    libcef.dll!content::ContentServiceManagerMainDelegate::~ContentServiceManagerMainDelegate() Line 21   C++
    libcef.dll!content::ContentServiceManagerMainDelegate::~ContentServiceManagerMainDelegate() Line 21   C++
    [Inline Frame] libcef.dll!std::__1::default_delete<content::ContentServiceManagerMainDelegate>::operator()(content::ContentServiceManagerMainDelegate * __ptr) Line 2338   C++
    [Inline Frame] libcef.dll!std::__1::unique_ptr<content::ContentServiceManagerMainDelegate,std::__1::default_delete<content::ContentServiceManagerMainDelegate> >::reset(content::ContentServiceManagerMainDelegate * __p) Line 2651   C++
    libcef.dll!CefContext::FinalizeShutdown() Line 638   C++
    libcef.dll!CefContext::Shutdown() Line 482   C++
    libcef.dll!CefShutdown() Line 272   C++
    jcef.dll!CefShutdown() Line 121   C++
    jcef.dll!Context::Shutdown() Line 179   C++
    jcef.dll!Java_org_cef_CefApp_N_1Shutdown(JNIEnv_ * env, _jobject * __formal) Line 45   C++

Hope someone can get to it. I'm getting quite tired of having my code randomly crash for seemingly no reason. I'll provide more info if needed.

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 6:22 am
by HarmfulBreeze
Also just found out there were Release Symbols...
Here is the stack trace from VS I get when using JCEF with the Release distrib and symbols:
Code: Select all
**this** was nullptr.
>   libcef.dll!SystemNetworkContextManager::CreateDefaultNetworkContextParams() Line 712   C++
    libcef.dll!ProfileNetworkContextService::CreateNetworkContextParams(bool in_memory, const base::FilePath & relative_partition_path) Line 439   C++
    libcef.dll!ProfileNetworkContextService::CreateNetworkContext(bool in_memory, const base::FilePath & relative_partition_path) Line 232   C++
    libcef.dll!Profile::CreateNetworkContext(bool in_memory, const base::FilePath & relative_partition_path) Line 279   C++
    libcef.dll!CefContentBrowserClient::CreateNetworkContext(content::BrowserContext * context, bool in_memory, const base::FilePath & relative_partition_path) Line 1292   C++
    libcef.dll!content::StoragePartitionImpl::InitNetworkContext() Line 2270   C++
    [Inline Frame] libcef.dll!base::OnceCallback<void ()>::Run() Line 98   C++
    libcef.dll!mojo::InterfaceEndpointClient::NotifyError(const base::Optional<mojo::DisconnectReason> & reason) Line 377   C++
    libcef.dll!mojo::internal::MultiplexRouter::ProcessNotifyErrorTask(mojo::internal::MultiplexRouter::Task * task, mojo::internal::MultiplexRouter::ClientCallBehavior client_call_behavior, base::SequencedTaskRunner * current_task_runner) Line 800   C++
    libcef.dll!mojo::internal::MultiplexRouter::ProcessTasks(mojo::internal::MultiplexRouter::ClientCallBehavior client_call_behavior, base::SequencedTaskRunner * current_task_runner) Line 708   C++
    libcef.dll!mojo::internal::MultiplexRouter::OnPipeConnectionError(bool force_async_dispatch) Line 682   C++
    [Inline Frame] libcef.dll!base::OnceCallback<void ()>::Run() Line 98   C++
    libcef.dll!mojo::Connector::HandleError(bool force_pipe_reset, bool force_async_handler) Line 663   C++
    [Inline Frame] libcef.dll!base::RepeatingCallback<void (unsigned int, const mojo::HandleSignalsState &)>::Run(unsigned int args, const mojo::HandleSignalsState & args) Line 132   C++
    libcef.dll!mojo::SimpleWatcher::OnHandleReady(int watch_id, unsigned int result, const mojo::HandleSignalsState & state) Line 293   C++
    [Inline Frame] libcef.dll!base::OnceCallback<void ()>::Run() Line 98   C++
    libcef.dll!base::TaskAnnotator::RunTask(const char * trace_event_name, base::PendingTask * pending_task) Line 142   C++
    libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow * continuation_lazy_now, bool * ran_task) Line 366   C++
    libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() Line 221   C++
    libcef.dll!base::MessagePumpForUI::DoRunLoop() Line 219   C++
    libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 77   C++
    libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool application_tasks_allowed, base::TimeDelta timeout) Line 463   C++
    libcef.dll!base::RunLoop::Run() Line 158   C++
    libcef.dll!CefUIThread::ThreadMain() Line 372   C++
    libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 105   C++

Now I do get a 0xC0000005 after calling the Dispose method, probably

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 10:10 am
by magreenblatt
The CreateNetworkContext crash was fixed in https://bitbucket.org/chromiumembedded/ ... n-shutdown.

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 10:21 am
by HarmfulBreeze
That's weird, because this crash comes from the latest JCEF commit. Am I missing something?

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 12:08 pm
by magreenblatt
HarmfulBreeze wrote:That's weird, because this crash comes from the latest JCEF commit. Am I missing something?

You need to update the CEF version used by your JCEF build. Change the CEF_VERSION value in CMakeLists.txt from "78.2.7+g9cd8bac+chromium-78.0.3904.70" to "78.3.9+gc7345f2+chromium-78.0.3904.108" and then re-run CMake.

Re: JVM Crash with swing Application

PostPosted: Mon Feb 17, 2020 1:00 pm
by HarmfulBreeze
Awesome, that fixed it. Thanks!