Closed GoogleCodeExporter closed 8 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
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
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
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:
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
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
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:
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:
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
> 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
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
@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
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:
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
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
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
> 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
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
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
Issue 23 has been merged into this issue.
Original comment by magreenb...@gmail.com
on 9 Jun 2014 at 5:33
Great work guys. Thanks for figuring this one out.
Original comment by magreenb...@gmail.com
on 9 Jun 2014 at 5:34
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:
@#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
@#39: And revision 80 adds signal_restore_posix.*
Original comment by magreenb...@gmail.com
on 17 Jun 2014 at 5:27
Original issue reported on code.google.com by
christop...@gmail.com
on 19 Feb 2014 at 3:26Attachments: