search

yueying0083 / javachromiumembedded

Automatically exported from code.google.com/p/javachromiumembedded
0 stars 0 forks source link

Mac JCEF frequently crashing in thread CrBrowserMain #41

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Download binary distribution jcef_binary_3.1650.1552.13_macosx64_preview.7z

2. sh compile.sh, sh run.sh
3. Browse around, resize main frame repeatedly, give focus in main frame and to 
other apps, repeat step 3. 

What is the expected output? What do you see instead?
Things often crash after 30s in a few mac systems I have here while going 
through step 3.

What version of the product are you using? On what operating system?
jcef_binary_3.1650.1552.13_macosx64_preview.7z. I also see this pb with the 
latest jcef source code.

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Mac 10.8.5

Please provide any additional information below.
I'm attaching one of the crash reports. The crashes almost always appear in 
thread CrBrowserMain, but the trace itself varies from crash to crash. Trying 
to get the dsym info but no success currently.

Original issue reported on code.google.com by christop...@gmail.com on 19 Feb 2014 at 3:26

Attachments:

GoogleCodeExporter commented 9 years ago 
Does it seem stable on your system? I know this is an experimental port, 
curious to know if it behaves well on other mac's?

Original comment by christop...@gmail.com on 19 Feb 2014 at 3:27

GoogleCodeExporter commented 9 years ago 
There have been many fixes since that preview. Try building yourself using the 
newest sources as described on the BranchesAndBuilding wiki page.

Original comment by magreenb...@gmail.com on 20 Feb 2014 at 4:51

GoogleCodeExporter commented 9 years ago 
Ack. Thanks for upgrading to cef 1750 :-)

With the latest, I see similar behavior when using the osr mode. e.g. I go back 
and forth between http://www.google.ca and http://www.cbc.ca, resize with the 
mouse in circles, give focus to other apps, return to the browser app. After a 
while, it crashes in the CrBrowserMain thread on my system. I'm using 1.7 64bit.

Thread 17 Crashed:: CrBrowserMain
0   ???                             0x0000000104286fc6 0 + 4364726214
1   ???                             0x00000000f80064d1 0 + 4160775377

Original comment by christop...@gmail.com on 20 Feb 2014 at 8:33

GoogleCodeExporter commented 9 years ago 
The non-osr mode always draws the browser area in the bottom left corner of the 
top window - screenshot attached. So for now the osr mode works better on the 
Mac.

Original comment by christop...@gmail.com on 20 Feb 2014 at 8:42

Attachments:

GoogleCodeExporter commented 9 years ago 
In non-osr mode, I also am able to crash when navigating between google.ca, 
cbc.ca, resizing, giving focus to other apps, returning. The crash occurs in 
the AWT event queue thread in that case.

Thread 18 Crashed:: Java: AWT-EventQueue-0
0   ???                             0x000000011108a20d 0 + 4580745741

Unfortunately I don't have a really clear list of steps to reproduce yet

Original comment by christop...@gmail.com on 20 Feb 2014 at 8:50

GoogleCodeExporter commented 9 years ago 
Can you replace "jcef_app.app/Contents/Frameworks/Chromium Embedded 
Framework.framework/Chromium Embedded Framework" with the Debug build from the 
CEF binary distribution and post the resulting stack trace?

Original comment by magreenb...@gmail.com on 20 Feb 2014 at 8:57

GoogleCodeExporter commented 9 years ago 
Here it is. Unfortunately, the CrBrowserMain trace is still not resolved

Original comment by christop...@gmail.com on 21 Feb 2014 at 2:36

Attachments:

GoogleCodeExporter commented 9 years ago 
This is a different crash. This one happened very early on, after the app shows 
up. And this time around the trace is resolved.

Full file attached

Thread 25 Crashed:: CrBrowserMain
0   org.chromium.ContentShell.framework 0x000000019d59ba27 
base::debug::BreakDebugger() + 23
1   org.chromium.ContentShell.framework 0x000000019d608e98 
logging::LogMessage::~LogMessage() + 920
2   org.chromium.ContentShell.framework 0x000000019d607993 
logging::LogMessage::~LogMessage() + 35
3   org.chromium.ContentShell.framework 0x000000019d383179 
CefBrowserInfo::remove_render_id(std::set<std::pair<int, int>, 
std::less<std::pair<int, int> >, std::allocator<std::pair<int, int> > >*, int, 
int) + 697
4   org.chromium.ContentShell.framework 0x000000019d383214 
CefBrowserInfo::remove_render_frame_id(int, int) + 68
5   org.chromium.ContentShell.framework 0x000000019d35ba6a 
CefBrowserHostImpl::RenderFrameDeleted(content::RenderFrameHost*) + 138
6   org.chromium.ContentShell.framework 0x000000019d35bac4 non-virtual thunk to 
CefBrowserHostImpl::RenderFrameDeleted(content::RenderFrameHost*) + 52
7   org.chromium.ContentShell.framework 0x000000019dfdd998 
content::WebContentsImpl::RenderFrameDeleted(content::RenderFrameHost*) + 136
8   org.chromium.ContentShell.framework 0x000000019dfdda04 non-virtual thunk to 
content::WebContentsImpl::RenderFrameDeleted(content::RenderFrameHost*) + 52
9   org.chromium.ContentShell.framework 0x000000019d9cf2d0 
content::RenderFrameHostImpl::~RenderFrameHostImpl() + 240
10  org.chromium.ContentShell.framework 0x000000019d9cf163 
content::RenderFrameHostImpl::~RenderFrameHostImpl() + 35
11  org.chromium.ContentShell.framework 0x000000019d9cf10a 
content::RenderFrameHostImpl::~RenderFrameHostImpl() + 42
12  org.chromium.ContentShell.framework 0x000000019de7429f 
base::DefaultDeleter<content::RenderFrameHostImpl>::operator()(content::RenderFr
ameHostImpl*) const + 63
13  org.chromium.ContentShell.framework 0x000000019de786f2 
base::internal::scoped_ptr_impl<content::RenderFrameHostImpl, 
base::DefaultDeleter<content::RenderFrameHostImpl> >::~scoped_ptr_impl() + 66
14  org.chromium.ContentShell.framework 0x000000019de78683 
base::internal::scoped_ptr_impl<content::RenderFrameHostImpl, 
base::DefaultDeleter<content::RenderFrameHostImpl> >::~scoped_ptr_impl() + 35
15  org.chromium.ContentShell.framework 0x000000019de78633 
scoped_ptr<content::RenderFrameHostImpl, 
base::DefaultDeleter<content::RenderFrameHostImpl> >::~scoped_ptr() + 35
16  org.chromium.ContentShell.framework 0x000000019de6b323 
scoped_ptr<content::RenderFrameHostImpl, 
base::DefaultDeleter<content::RenderFrameHostImpl> >::~scoped_ptr() + 35
17  org.chromium.ContentShell.framework 0x000000019de5afa1 
content::RenderViewHostImpl::~RenderViewHostImpl() + 721
18  org.chromium.ContentShell.framework 0x000000019de5ab61 
content::RenderViewHostImpl::~RenderViewHostImpl() + 49
19  org.chromium.ContentShell.framework 0x000000019de5aafa 
content::RenderViewHostImpl::~RenderViewHostImpl() + 42
20  org.chromium.ContentShell.framework 0x000000019de5ac0c non-virtual thunk to 
content::RenderViewHostImpl::~RenderViewHostImpl() + 44
21  org.chromium.ContentShell.framework 0x000000019de8dd55 
content::RenderWidgetHostImpl::Destroy() + 213
22  org.chromium.ContentShell.framework 0x000000019de8da9a 
content::RenderWidgetHostImpl::Shutdown() + 330
23  org.chromium.ContentShell.framework 0x000000019de68212 
content::RenderViewHostImpl::Shutdown() + 274
24  org.chromium.ContentShell.framework 0x000000019d9d70a2 
content::RenderFrameHostManager::CommitPending() + 1906
25  org.chromium.ContentShell.framework 0x000000019d9d55a2 
content::RenderFrameHostManager::UpdateRendererStateForNavigate(content::Navigat
ionEntryImpl const&) + 930
26  org.chromium.ContentShell.framework 0x000000019d9d4f46 
content::RenderFrameHostManager::Navigate(content::NavigationEntryImpl const&) 
+ 214
27  org.chromium.ContentShell.framework 0x000000019dfd82fd 
content::WebContentsImpl::NavigateToEntry(content::NavigationEntryImpl const&, 
content::NavigationController::ReloadType) + 493
28  org.chromium.ContentShell.framework 0x000000019dfd80db 
content::WebContentsImpl::NavigateToPendingEntry(content::NavigationController::
ReloadType) + 75
29  org.chromium.ContentShell.framework 0x000000019dfd87f2 non-virtual thunk to 
content::WebContentsImpl::NavigateToPendingEntry(content::NavigationController::
ReloadType) + 50
30  org.chromium.ContentShell.framework 0x000000019d9b854f 
content::NavigationControllerImpl::NavigateToPendingEntry(content::NavigationCon
troller::ReloadType) + 575
31  org.chromium.ContentShell.framework 0x000000019d9b8a50 
content::NavigationControllerImpl::LoadEntry(content::NavigationEntryImpl*) + 64
32  org.chromium.ContentShell.framework 0x000000019d9ba925 
content::NavigationControllerImpl::LoadURLWithParams(content::NavigationControll
er::LoadURLParams const&) + 1925
33  org.chromium.ContentShell.framework 0x000000019d9ba167 
content::NavigationControllerImpl::LoadURL(GURL const&, content::Referrer 
const&, content::PageTransition, std::string const&) + 199
34  org.chromium.ContentShell.framework 0x000000019d34e63c 
CefBrowserHostImpl::LoadURL(long long, std::string const&, content::Referrer 
const&, content::PageTransition, std::string const&) + 684
35  org.chromium.ContentShell.framework 0x000000019d3d155c 
CefFrameHostImpl::LoadURL(CefStringBase<CefStringTraitsUTF16> const&) + 316
36  org.chromium.ContentShell.framework 0x000000019d2e8d21 
frame_load_url(_cef_frame_t*, _cef_string_utf16_t const*) + 465
37  libjcef.dylib                   0x0000000199d93f6c 
CefFrameCToCpp::LoadURL(CefStringBase<CefStringTraitsUTF16> const&) + 252 
(frame_ctocpp.cc:177)
38  libjcef.dylib                   0x0000000199d2414d 
Java_org_cef_CefBrowser_1N_N_1LoadURL + 189 (CefBrowser_N.cpp:165)
39  ???                             0x0000000103231698 0 + 4347598488
40  ???                             0x0000000103225058 0 + 4347547736
41  ???                             0x0000000103225706 0 + 4347549446
42  ???                             0x0000000103225706 0 + 4347549446
43  ???                             0x0000000103225058 0 + 4347547736
44  ???                             0x0000000103225058 0 + 4347547736
45  ???                             0x0000000103225706 0 + 4347549446
46  ???                             0x0000000103225350 0 + 4347548496
47  ???                             0x0000000103225350 0 + 4347548496
48  ???                             0x0000000103225350 0 + 4347548496
49  ???                             0x0000000103225058 0 + 4347547736
50  ???                             0x0000000103225058 0 + 4347547736
51  ???                             0x0000000103225058 0 + 4347547736
52  ???                             0x0000000103225058 0 + 4347547736
53  ???                             0x0000000103225058 0 + 4347547736
54  ???                             0x0000000103225058 0 + 4347547736
55  ???                             0x0000000103225058 0 + 4347547736
56  ???                             0x0000000103225350 0 + 4347548496
57  ???                             0x0000000103225350 0 + 4347548496
58  ???                             0x0000000103225350 0 + 4347548496
59  ???                             0x0000000103225350 0 + 4347548496
60  ???                             0x0000000103225058 0 + 4347547736
61  ???                             0x0000000103225058 0 + 4347547736
62  ???                             0x0000000103225058 0 + 4347547736
63  ???                             0x0000000103225058 0 + 4347547736
64  ???                             0x0000000103225058 0 + 4347547736
65  ???                             0x0000000103225058 0 + 4347547736
66  ???                             0x0000000103225233 0 + 4347548211
67  ???                             0x000000010321f4e7 0 + 4347524327
68  libjvm.dylib                    0x0000000102950bb0 
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) 
+ 554
69  libjvm.dylib                    0x0000000102950980 
JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
70  libjvm.dylib                    0x00000001029a4264 JVM_DoPrivileged + 1041
71  ???                             0x0000000103231698 0 + 4347598488
72  ???                             0x0000000103225233 0 + 4347548211
73  ???                             0x0000000103225233 0 + 4347548211
74  ???                             0x00000001032258e1 0 + 4347549921
75  ???                             0x0000000103225233 0 + 4347548211
76  ???                             0x000000010321f4e7 0 + 4347524327
77  libjvm.dylib                    0x0000000102950bb0 
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) 
+ 554
78  libjvm.dylib                    0x0000000102950980 
JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
79  libjvm.dylib                    0x00000001029a4264 JVM_DoPrivileged + 1041
80  ???                             0x0000000103231698 0 + 4347598488
81  ???                             0x0000000103225233 0 + 4347548211
82  ???                             0x00000001032258e1 0 + 4347549921
83  ???                             0x0000000103225058 0 + 4347547736
84  ???                             0x0000000103225058 0 + 4347547736
85  ???                             0x0000000103225058 0 + 4347547736
86  ???                             0x0000000103225058 0 + 4347547736
87  ???                             0x0000000103225058 0 + 4347547736
88  ???                             0x0000000103225058 0 + 4347547736
89  ???                             0x000000010321f4e7 0 + 4347524327
90  libjvm.dylib                    0x0000000102950bb0 
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) 
+ 554
91  libjvm.dylib                    0x00000001029510c7 
JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, 
JavaCallArguments*, Thread*) + 283
92  libjvm.dylib                    0x0000000102951204 
JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, 
Thread*) + 74
93  libjvm.dylib                    0x00000001029a01ea thread_entry(JavaThread*, 
Thread*) + 173
94  libjvm.dylib                    0x0000000102b69b57 
JavaThread::thread_main_inner() + 155
95  libjvm.dylib                    0x0000000102b6b25f JavaThread::run() + 419
96  libjvm.dylib                    0x0000000102a951d6 java_start(Thread*) + 294
97  libsystem_pthread.dylib         0x00007fff83655899 _pthread_body + 138
98  libsystem_pthread.dylib         0x00007fff8365572a _pthread_start + 137
99  libsystem_pthread.dylib         0x00007fff83659fc9 thread_start + 13

Original comment by christop...@gmail.com on 21 Feb 2014 at 2:46

Attachments:

GoogleCodeExporter commented 9 years ago 
So in summary:
In osr mode, crash occurs in CrBrowserMain thread
In non osr mode, crash occurs in AWT-EventQueue thread (e.g. when app becomes 
the active app)

If you can think of other things I can do to provide more useful traces, let me 
know
I've also noticed the non osr mode drew correctly on my mac with the latest OS 
10.9.1 and XCode 5.0.2.  So maybe I should not build the jcef on an old Mac and 
old XCode. What OS / XCode do you use yourself?

Original comment by christop...@gmail.com on 21 Feb 2014 at 3:19

GoogleCodeExporter commented 9 years ago 
Update - trying the latest JCEF (r39) on Mac 10.9 with Java 8 64bit (official 
8), JCEF/CEF debug build.

I start jcef_app from the Finder. I do the following steps: go to 
www.google.ca, www.cbc.ca, other sites, go back and forth, reload/abort, etc. 
After a while, I crash in the AWT event loop. And no symbolic information :-(

On the Mac, util_mac.mm has to play tricks (swizzle) to intercept the events on 
the AWT NSApplication. That sounds like a possible way to mess up the AWT event 
thread? To test that theory, is there some old code lying around that would 
pump the events from Chromium without passing through the AWT NSApplication?

Original comment by christop...@gmail.com on 3 Apr 2014 at 9:34

GoogleCodeExporter commented 9 years ago 
Here's what a typical crash look like. Suspicious about these 2 threads that 
are both related to the event loop.

Process:         JavaAppLauncher [1708]
Path:            
/Users/USER/Desktop/*/jcef_app.app/Contents/MacOS/JavaAppLauncher
Identifier:      org.jcef.jcef_app
Version:         1.0 (1)
Code Type:       X86-64 (Native)
Parent Process:  launchd [152]
Responsible:     JavaAppLauncher [1708]
User ID:         501

Date/Time:       2014-04-03 17:24:59.593 -0400
OS Version:      Mac OS X 10.9.2 (13C64)
Report Version:  11
Anonymous UUID:  9C4059CA-2339-97AD-66CF-27DEB7EE1DF8

Sleep/Wake UUID: F48792EF-0926-43D7-993E-F28FD2636863

Crashed Thread:  19  Java: AWT-EventQueue-0

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000010459a000

VM Regions Near 0x10459a000:
    __LINKEDIT             000000010458c000-000000010459a000 [   56K] r--/rwx SM=COW  /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/libjava.dylib
--> VM_ALLOCATE            000000010459a000-000000010459b000 [    4K] ---/rwx 
SM=COW  
    mapped file            000000010459b000-00000001045a3000 [   32K] rw-/rwx SM=PRV  /private/var/folders/*

Thread 0:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff98d08a1a mach_msg_trap + 10
1   libsystem_kernel.dylib          0x00007fff98d07d18 mach_msg + 64
2   com.apple.CoreFoundation        0x00007fff92a79155 
__CFRunLoopServiceMachPort + 181
3   com.apple.CoreFoundation        0x00007fff92a78779 __CFRunLoopRun + 1161
4   com.apple.CoreFoundation        0x00007fff92a780b5 CFRunLoopRunSpecific + 309
5   com.apple.HIToolbox             0x00007fff98548a0d RunCurrentEventLoopInMode 
+ 226
6   com.apple.HIToolbox             0x00007fff985487b7 ReceiveNextEventCommon + 
479
7   com.apple.HIToolbox             0x00007fff985485bc 
_BlockUntilNextEventMatchingListInModeWithFilter + 65
8   com.apple.AppKit                0x00007fff91eac3de _DPSNextEvent + 1434
9   com.apple.AppKit                0x00007fff91eaba2b -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
10  libosxapp.dylib                 0x00000001770e16d4 -[NSApplicationAWT 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
11  org.chromium.ContentShell.framework 0x000000017b0c0a30 0x17afa5000 + 1161776
12  org.chromium.ContentShell.framework 0x000000017b0c038c 0x17afa5000 + 1160076
13  org.chromium.ContentShell.framework 0x000000017b0fec40 0x17afa5000 + 1416256
14  org.chromium.ContentShell.framework 0x000000017b117cea 0x17afa5000 + 1518826
15  org.chromium.ContentShell.framework 0x000000017b0fe5dd 0x17afa5000 + 1414621
16  org.chromium.ContentShell.framework 0x000000017b017102 0x17afa5000 + 467202
17  libjcef.dylib                   0x000000017ad8413b CefRunMessageLoop() + 27 
(libcef_dll_wrapper.cc:255)
18  libjcef.dylib                   0x000000017ad5df7f +[CefHandler initialize:] 
+ 239 (util_mac.mm:199)
19  com.apple.Foundation            0x00007fff96a6b13e __NSThreadPerformPerform 
+ 229
20  com.apple.CoreFoundation        0x00007fff92a87731 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
21  com.apple.CoreFoundation        0x00007fff92a78f69 __CFRunLoopDoSources0 + 
441
22  com.apple.CoreFoundation        0x00007fff92a7862f __CFRunLoopRun + 831
23  com.apple.CoreFoundation        0x00007fff92a780b5 CFRunLoopRunSpecific + 309
24  com.apple.HIToolbox             0x00007fff98548a0d RunCurrentEventLoopInMode 
+ 226
25  com.apple.HIToolbox             0x00007fff985487b7 ReceiveNextEventCommon + 
479
26  com.apple.HIToolbox             0x00007fff985485bc 
_BlockUntilNextEventMatchingListInModeWithFilter + 65
27  com.apple.AppKit                0x00007fff91eac3de _DPSNextEvent + 1434
28  com.apple.AppKit                0x00007fff91eaba2b -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
29  libosxapp.dylib                 0x00000001770e16d4 -[NSApplicationAWT 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
30  com.apple.AppKit                0x00007fff91e9fb2c -[NSApplication run] + 553
31  libosxapp.dylib                 0x00000001770e14e8 +[NSApplicationAWT 
runAWTLoopWithApp:] + 156
32  libawt_lwawt.dylib              0x0000000177071afb -[AWTStarter starter:] + 
873
33  com.apple.Foundation            0x00007fff96a6b13e __NSThreadPerformPerform 
+ 229
34  com.apple.CoreFoundation        0x00007fff92a87731 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
35  com.apple.CoreFoundation        0x00007fff92a78ea2 __CFRunLoopDoSources0 + 
242
36  com.apple.CoreFoundation        0x00007fff92a7862f __CFRunLoopRun + 831
37  com.apple.CoreFoundation        0x00007fff92a780b5 CFRunLoopRunSpecific + 309
38  libjli.dylib                    0x00000001034a8b33 
CreateExecutionEnvironment + 871
39  libjli.dylib                    0x00000001034a4ad4 JLI_Launch + 1952
40  org.jcef.jcef_app               0x000000010342b990 launch + 5696
41  org.jcef.jcef_app               0x000000010342a136 main + 102
42  org.jcef.jcef_app               0x000000010342a0c4 start + 52

Thread 19 Crashed:: Java: AWT-EventQueue-0
0   ???                             0x00000001046ff732 0 + 4369413938

Original comment by christop...@gmail.com on 3 Apr 2014 at 9:36

GoogleCodeExporter commented 9 years ago 
I also encountered similar random crashes without resolvable symbols in Mac. 
From the crashed address space, I think it's belong to jvm. Maybe I'll try to 
find a debug build of java.

Original comment by wjy...@gmail.com on 7 Apr 2014 at 8:31

GoogleCodeExporter commented 9 years ago 
Please test with revision 40 and let me know if you're still experiencing the 
above crashes. There's still one shutdown crash on Mac -- if you select "Quit 
MainFrame" from the top application menu without closing the window first.

Original comment by magreenb...@gmail.com on 11 Apr 2014 at 4:10

GoogleCodeExporter commented 9 years ago 
Catching up with revision 40 and will let you know how it goes on my Mac...

Original comment by christop...@gmail.com on 11 Apr 2014 at 6:09

GoogleCodeExporter commented 9 years ago 
Some early feedback on testing revision 40

Mac OS 10.9, latest XCode 5.1, default MainFrame.java (non-osr, double click on 
jcef_app.app from finder)
MainFrame appears very stable as long as I don't do any of the following: 
resize, bring another app to the forefront, click on the menu bar in the 
MainFrame jframe, bring up popup menu. I was able to visit many sites, enter 
text inside browser area and inside Swing input field and not crash.

However, when starting to resize, bring other apps to the front, click menu 
bars, then random crashes will occur. Either in AWT Event Queue thread, either 
in CrBrowserMain thread. In both cases, the thread in the crash was pretty 
useless :-(

I'll keep testing from within lldb with 1.7 VM and provide traces. Hopefully we 
can narrow down a particular type of random crash - e.g. the random crash after 
resizing. I confess the threading involved in all the callbacks in Java JCEF 
and C/objective-c code/event loops isn't yet cleared to me...

Original comment by christop...@gmail.com on 11 Apr 2014 at 7:29

GoogleCodeExporter commented 9 years ago 
MainFrame.java R40 running inside lldb with Open JDK 1.7

When frame comes up and displays google page, grab bottom right corner with 
mouse and resize endlessly drawing circles. In some cases, randomly, this 
causes the following crash. That's the simplest series of steps I have so far. 
Revision 40 is probably an important step in the right direction, there are 
probably more than one tricky threading aspect to get right.

* thread #24: tid = 0x1be97, 0x00000001024251ca, name = 'Java: 
AWT-EventQueue-0', stop reason = signal SIGSEGV
    frame #0: 0x00000001024251ca
-> 0x1024251ca:  movl   0x8(%r12,%rbp,8), %r11d
   0x1024251cf:  movq   0x28(%r12,%r11,8), %r9
   0x1024251d4:  leaq   (%r12,%r11,8), %rsi
   0x1024251d8:  movabsq $0x7cc58d230, %rax
(lldb) thread backtrace 
* thread #24: tid = 0x1be97, 0x00000001024251ca, name = 'Java: 
AWT-EventQueue-0', stop reason = signal SIGSEGV
  * frame #0: 0x00000001024251ca

I attached the stack traces in dump.txt

Original comment by christop...@gmail.com on 11 Apr 2014 at 8:15

Attachments:

GoogleCodeExporter commented 9 years ago 
In my testings a few days ago, these non-resolvable symbols are actually 
compiled Java code, so these should not be jvm issues. I added breakpoints to 
all functions that can be called during the process in eclipse, such as resize 
event handler in Java. I think java in Mac does not emit null pointer 
exception, but SIGSEGV when accessing null pointers in some cases. This issue 
should be caused somewhere in java side when accessing null objects, like 
obj.getA().getB()  If getA() returns null, it will be SIGSEGV.

Original comment by wjy...@gmail.com on 15 Apr 2014 at 3:06

GoogleCodeExporter commented 9 years ago 
Interesting... I had observed things were much more stable when the mixed mode 
was off (-Xint). But that's often the case when things run slower...

I was wondering if we were deleting/freeing some Java or C++ or Objective-C 
object on one thread, but still referencing it from another callback and 
randomly crashing when its memory actually gets reused. The life cycle of some 
Java objects is a bit tricky with some global JNI references being held on the 
native side. Maybe there's no pb in the JCEF code but we trigger a bug in the 
compiled Java code on the Mac when trying to access an object that should not 
have been GC'ed. I'll pay attention to the GC again.

Another thing I was wondering about, where certain things done on the wrong 
thread between AWT EDT and CrBrowserMain in particular. But I'd rather be 
chasing a pb with NPE and an object being reclaimed too early...

Original comment by christop...@gmail.com on 16 Apr 2014 at 1:30

GoogleCodeExporter commented 9 years ago 
I'd like to give some examples on null object crashes. It's in the "Notes on 
JVM" and "CTabFolder" sections of this web page 
https://code.google.com/p/javacef/wiki/CEF3Instructions#Mac_Specific

Maybe the bug is in some third-party libraries or in some not obvious places. 
Most probably the bug is due to accessing null pointers.

Original comment by wjy...@gmail.com on 6 May 2014 at 1:55

GoogleCodeExporter commented 9 years ago 
comment 19: interesting, @wjy... Running with -Xint (no jit), I don't see NPE's 
but will keep an eye for those.

Original comment by christop...@gmail.com on 8 May 2014 at 1:18

GoogleCodeExporter commented 9 years ago 
When I run tests.simple.MainFrame (JCEF revision 60) on Mac, using -Xcheck:jni 
, I get this output:
Warning: SIGSEGV handler expected:libjvm.dylib+0x4188a2  
found:0x0000000000000000

At 
http://stackoverflow.com/questions/15790403/what-does-consider-using-jsig-librar
y-mean , it explains a workaround is to put the libjsig library. It mentions 
this is related to NPE causing crashes otherwise

"This is important, as from my understanding of the JVM, it uses the SIGSEGV 
signal to determine if you're dereferencing a null pointer, and if you are it 
will throw a NullPointerException."

So wjy..., that seems to relate to the pb you are reporting. Maybe not a pb 
with the JIT but with libjcef installing its own signal handlers and upon NPE 
VM causes a sigsev instead?

Original comment by christop...@gmail.com on 14 May 2014 at 4:58

GoogleCodeExporter commented 9 years ago 
Another link around this SIGSEGV missing handler: 
http://root.cern.ch/phpBB3/viewtopic.php?t=8231

Original comment by christop...@gmail.com on 14 May 2014 at 4:59

GoogleCodeExporter commented 9 years ago 
one way to eliminate the SIGSEGV handler override (in your dev environment) is 
to set this environment variable before launching java:
Point DYLD_INSERT_LIBRARIES to
/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre/lib/libjsig.
dylib

After that, when running with -Xcheck:jni we no longer get warnings about 
Warning: SIGSEGV handler expected:... Instead we get:
Info: libjsig is activated, all active signal checking is disabled

wjy... in comment 19, does that help you workaround the null object crashes you 
encountered?

Original comment by christop...@gmail.com on 14 May 2014 at 6:14

GoogleCodeExporter commented 9 years ago 
I tested this on Linux using LD_PRELOAD="$JAVA_HOME/jre/lib/amd64/libjsig.so". 
The program does not have SIGSEGV anymore. I think you are right. The cef 
library registers signal handlers and overrides the jvm signal handlers, so the 
null pointer exception is not handled properly in the cef library. I'll test on 
Mac later. Maybe we should recommend @magreenblatt to use libjsig as a solution 
on Mac and Linux.

Original comment by wjy...@gmail.com on 16 May 2014 at 3:09

GoogleCodeExporter commented 9 years ago 
Hi Christoph and wjy…,

thank you very much for your good analyzes around this issue. That helps a lot 
:-)

I've tested your suggested workaround using "libjsig.dylib" on a Mac.
Loading the lib makes it much harder to get a SIGSEGV but unfortunately not 
impossible:

After clicking a while between the different test cases, I still got a crash 
caused by sigsegv.

> Crashed Thread:  27  Java: AWT-EventQueue-0
>
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008

So I think that there are still some other problems beside this signal-handling 
thing to figure out...

Original comment by k...@censhare.de on 20 May 2014 at 12:20

GoogleCodeExporter commented 9 years ago 
> After clicking a while between the different test cases, I still got a crash 
caused by sigsegv.
Yes, the Mac is still very unstable when the jit is on. Could it be because on 
the Mac, UI work has to be done on the AppKit thread, AWT/Swing eventing has to 
be done through EDT thread and the code in util_mac.mm doesn't participate in 
any AWT native locking at all even though it interferes with the AppKit thread? 
I've just started looking into things like LWCToolkit and a lot of locking 
seems to be taking place. If anyone is an expert in AWT/Swing's Mac 
implementation, speak up :-)

Original comment by christop...@gmail.com on 20 May 2014 at 1:07

GoogleCodeExporter commented 9 years ago 
I tested DYLD_INSERT_LIBRARIES on Mac. It still had some other crashes, and I 
will try to get a crash trace next time. I also tested to use libjsig.dylib in 
32-bit build, but apple's JDK 6 didn't provide this library. Here's the method 
I tried to build this library for reference:

Get the file at
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/src/os/bsd/vm/jsig.c

Then
clang jsig.c -shared -o libjsig.dylib -arch i386 -arch x86_64

But I think this library is GPL-licensed. Does the use of DYLD_INSERT_LIBRARIES 
or LD_PRELOAD mean linking/using GPL libraries and affect the license of the 
project?

Original comment by wjy...@gmail.com on 23 May 2014 at 3:01

GoogleCodeExporter commented 9 years ago 
@comment#27: It appears to be GPLv2 licensed which means we can't use or 
distribute it with JCEF.

Original comment by magreenb...@gmail.com on 23 May 2014 at 3:07

GoogleCodeExporter commented 9 years ago 
Here's a reproducible test case TestBusyEDT.java . I use Mac, jcef revision 60, 
jdk 1.7 64bit .
Can you confirm this crashes for you as well?

Start the app. Google should come up fine. Then click on the top button. After 
about 80 iterations, the app crashes in EDT jitted code. The libjsig.dylib does 
nothing in this case. Disabling the jit with -Xint on the other hand keeps the 
app running pretty well.

It looks like the EDT thread and CEF don't play nicely with each other. As a 
result, when we embed Chromium in an app that runs lots of jobs on the EDT and 
trigger lots of AWT/Swing activities, the app quickly crashes as well.

The test app below is slightly adapted from simple Mainframe.java. I added a 
button that keeps the EDT thread busy as follow.

int counter = 0;

void doSomeEDTWork() {      
    SwingUtilities.invokeLater(new Runnable() {

        @Override
        public void run() {
            counter++;
            System.out.println("Busy EDT: "+counter);
            String text = address_.getText();
            text += "hi! ";
            if (text.length() > 1000)
                text = "";
            address_.setText(text);
            SwingUtilities.invokeLater(this);
        }
    });
}

Original comment by christop...@gmail.com on 26 May 2014 at 7:16

Attachments:

GoogleCodeExporter commented 9 years ago 
With jdk1.8 64bit, the test above doesn't crash after 80 iterations. Click on 
the top button, then resize the frame. Similar crash. The JDK's version impacts 
how this pb is triggered.

Original comment by christop...@gmail.com on 26 May 2014 at 7:36

GoogleCodeExporter commented 9 years ago 
I'm implementing cef in SWT, and busy SWT thread does not crash on Mac. The 
following code changes the window title and tab title.

display.asyncExec(new Runnable() {
    public void run() {
        if (shell.isDisposed())
            return;
        String test = shell.getText();
        test += "test ";
        if (test.length() > 10)
            test = "";
        shell.setText(test);
        if (folder.getItems().length > 0 && !folder.getItem(0).isDisposed())
        folder.getItem(0).setText(test);

        display.asyncExec(this);
    }
});

The signal handling can be shared between AWT (jcef) and SWT (javacef). I plan 
to make some signal handling code by myself to avoid the GPLv2 libjsig.

Original comment by wjy...@gmail.com on 27 May 2014 at 2:24

GoogleCodeExporter commented 9 years ago 
I tried DYLD_INSERT_LIBRARIES=libjsig.dylib again. I found out that the 
"signal" and "sigaction" function calls are not redirected to libjsig.dylib, so 
the signals are still not handled properly and cause crashes. This is either a 
dyld bug or a jvm bug on Mac. (I think jvm should use 'dlsym(RTLD_DEFAULT, 
"sigaction")' instead of directly calling 'sigaction' for this case.)  
LD_PRELOAD=libjsig.so works correctly on Linux.

As @magreenblatt mentioned we can't use libjsig, I found the place where cef 
cleared the signal handlers. The following warning posted in #21 is caused by 
content::SetupSignalHandlers() that is called during CefInitialize().

Warning: SIGSEGV handler expected:libjvm.dylib+0x4188a2  
found:0x0000000000000000

https://code.google.com/p/chromium/codesearch#chromium/src/content/app/content_m
ain_runner.cc&l=146&q=content::SetupSignalHandlers&type=cs&sq=package:chromium

My solution was to backup the signal handlers before CefInitialize and restore 
them after CefInitialize. This also means you can not have any custom signal 
handlers unless you chain them by yourself. My patches are at:

https://code.google.com/p/javacef/source/detail?r=c9dce5d9341c667f1a64e7aaeb1967
97de091850
https://code.google.com/p/javacef/source/detail?r=811b86ae268838151699ed07dcc6ca
2535e30ce6

After these patches, I don't see any null pointer crashes so far. Feel free to 
code review my patch or copy them to this project.

Original comment by wjy...@gmail.com on 8 Jun 2014 at 6:36

GoogleCodeExporter commented 9 years ago 
> After these patches, I don't see any null pointer crashes so far
Looking forward to trying those next week and see if these also avoid the 
crashes I see myself. Really interesting :-)

Original comment by christop...@gmail.com on 8 Jun 2014 at 10:48

GoogleCodeExporter commented 9 years ago 
comment 32 - the patch is fixing the crash pbs I have experienced all these 
months.

So it looks like this nailed a big one - CefInitialize messes up with the 
signal handlers used by the JVM and causes these weird crashes in JITt'ed code 
randomly later.
I'm testing this more, but that's an awesome day so far :-)

Original comment by christop...@gmail.com on 9 Jun 2014 at 5:16

GoogleCodeExporter commented 9 years ago 
Also seems to address the crash described in 
https://code.google.com/p/javachromiumembedded/issues/detail?id=23

Original comment by christop...@gmail.com on 9 Jun 2014 at 5:32

GoogleCodeExporter commented 9 years ago 
Issue 23 has been merged into this issue.

Original comment by magreenb...@gmail.com on 9 Jun 2014 at 5:33

GoogleCodeExporter commented 9 years ago 
Great work guys. Thanks for figuring this one out.

Original comment by magreenb...@gmail.com on 9 Jun 2014 at 5:34

GoogleCodeExporter commented 9 years ago 
Thank you very much for finding a solution for that annoying issue. 
You saved me some headaches and many hours of work :-)

@Marshall:
To simplify committing this great solution, I've created a simple patch file 
which contains the files signal_restore_posix.cpp/.h from wjy…@gmail.com and 
the function calls (BackupSignalHandlers() and RestoreSignalHandlers() in 
CefApp.cpp.

Original comment by k...@censhare.de on 10 Jun 2014 at 6:04

Attachments:

GoogleCodeExporter commented 9 years ago 
@#38: Thanks, added in revision 79 with changes:
- Use standard copyright header.
- Use global array instead of stl container.
- Fix various style issues.

Original comment by magreenb...@gmail.com on 17 Jun 2014 at 5:25

GoogleCodeExporter commented 9 years ago 
@#39: And revision 80 adds signal_restore_posix.*

Original comment by magreenb...@gmail.com on 17 Jun 2014 at 5:27