CEF macOS 12.10 and 10.11

Do not post support requests, bug reports or feature requests. Discuss CEF here. Non-CEF related discussion goes in General Discussion!

CEF macOS 12.10 and 10.11

Postby gabyx » Fri Feb 23, 2018 11:11 am

We include CEF directly in our Project CMake with
find_package(CEF)
which then loads cef_macros.cmake and cef_variables.cmake form the binary distribution and unfortunately injects global cmake variables (not the good way of providing a cmake supported library)
into our project file. https://github.com/gabyx/ExecutionGraph/blob/0684909eefd6691f296b8c45a179f569ae5efe39/gui/CMakeLists.txt#L15

As I understand the wrapper (on macOs 10.12.6) builds with very specific flags:
here some sample output of the build:
Code: Select all
/usr/local/opt/llvm/bin/clang++  -DWRAPPING_CEF_SHARED -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -I/Users/simon/Dev/workspaces/privat/ExecutionGraph/buildExternal/cefbinaries/cefbinaries-src  -I/usr/local/opt/llvm/include -I/usr/local/opt/llvm/include/c++/v1/ -g -arch x86_64 -mmacosx-version-min=10.9   -fno-strict-aliasing -fstack-protector -funwind-tables -fvisibility=hidden -Wall -Werror -Wextra -Wendif-labels -Wnewline-eof -Wno-missing-field-initializers -Wno-unused-parameter -mmacosx-version-min=10.9 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fobjc-call-cxx-cdtors -fvisibility-inlines-hidden -std=gnu++11 -Wno-narrowing -Wsign-compare -Wno-undefined-var-template -O0 -g -std=c++1z -o CMakeFiles/libcef_dll_wrapper.dir/cpptoc/extension_handler_cpptoc.cc.o -c /Users/simon/Dev/workspaces/privat/ExecutionGraph/buildExternal/cefbinaries/cefbinaries-src/libcef_dll/cpptoc/extension_handler_cpptoc.cc


Our Application which links to the cef libraries
[url]https://github.com/gabyx/ExecutionGraph/blob/0684909eefd6691f296b8c45a179f569ae5efe39/gui/executionGraphGui/CMakeLists.txt#L201
[/url] has the same setup procedure as "cef-simple" except that we use a more modern C++ Standard: c++17 and use the standart flags set by cmake (e.g. exceptions are enabled and we use rtti, also we do not use it...)

On macOS 10.11 our executable builds and links perfectly and the startup works.
On macOS 10.12.6 the executable builds but crashes at startup. (the original cef-simple however works)

So what I did is I modified the original cef-simple executable to exactly use the same flags as I use for my app (see the crash dump)
I am at the moment with no clue what the problem is and any help would be appreciated!
Can we not build an app with different C++ flags while linking to CEF binaries (which was build with its own flags)?
Thanks a lot!

The crash dump I get is the following:

Code: Select all
Process:               CEFSimple [11483]
Path:                  /Users/USER/*/CEFSimple.app/Contents/MacOS/CEFSimple
Identifier:            org.cef.cefsimple
Version:               1.0
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           CEFSimple [11483]
User ID:               501

Date/Time:             2018-02-23 10:19:03.702 +0100
OS Version:            Mac OS X 10.12.6 (16G1114)
Report Version:        12
Anonymous UUID:        E9149922-0BC8-76E2-3531-3CF2479112FC

Sleep/Wake UUID:       DF64C42E-00BA-4DA7-8FBE-3C6F045D35DB

Time Awake Since Boot: 17000 seconds
Time Since Wake:       1900 seconds

System Integrity Protection: enabled

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Trace/BPT trap: 5
Termination Reason:    Namespace SIGNAL, Code 0x5
Terminating Process:   exc handler [0]

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   org.chromium.ContentShell.framework   0x00000001157d0818 0x1131fd000 + 39663640
1   org.chromium.ContentShell.framework   0x00000001157d054d 0x1131fd000 + 39662925
2   libsystem_malloc.dylib           0x00007fffc150d282 malloc_zone_malloc + 107
3   libsystem_malloc.dylib           0x00007fffc150d1a6 malloc_set_zone_name + 104
4   libclang_rt.asan_osx_dynamic.dylib   0x000000010cdf8f6d wrap_malloc_set_zone_name + 173
5   libdispatch.dylib                0x00007fffc13558fc _dispatch_client_callout + 8
6   libdispatch.dylib                0x00007fffc13558b9 dispatch_once_f + 38
7   com.apple.QuartzCore             0x00007fffb172a5f3 get_malloc_zone + 43
8   com.apple.QuartzCore             0x00007fffb172a647 x_mem_alloc + 14
9   com.apple.QuartzCore             0x00007fffb170ad5d x_list_prepend + 23
10  com.apple.QuartzCore             0x00007fffb16accbb CA::Transaction::add_commit_handler(void () block_pointer, CATransactionPhase) + 119
11  com.apple.AppKit                 0x00007fffa93dee21 +[_NSCGSTransaction currentTransaction] + 436
12  com.apple.AppKit                 0x00007fffa93df172 NSCGSTransactionSetObjectForKey + 49
13  com.apple.AppKit                 0x00007fffa943bfeb +[NSCGSWindow(NSCGSWindowApplicationOrdering) orderApplicationWindowsFront] + 18
14  com.apple.AppKit                 0x00007fffa96ee40a __54-[NSApplication _orderWindowsAndSwitchToSpaceIfNeeded]_block_invoke + 14
15  com.apple.AppKit                 0x00007fffa96ee3f6 -[NSApplication _orderWindowsAndSwitchToSpaceIfNeeded] + 89
16  com.apple.AppKit                 0x00007fffa943b8c9 -[NSApplication _doUnhideWithoutActivationMaybeFakingIt:] + 169
17  com.apple.AppKit                 0x00007fffa943b757 _hideShowHandler + 172
18  com.apple.HIToolbox              0x00007fffaacf9d85 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1708
19  com.apple.HIToolbox              0x00007fffaacf8ff6 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 428
20  com.apple.HIToolbox              0x00007fffaad0ed14 SendEventToEventTarget + 40
21  com.apple.AppKit                 0x00007fffa92b91c4 _DPSNextEvent + 3024
22  com.apple.AppKit                 0x00007fffa9a347ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
23  com.apple.AppKit                 0x00007fffa92ad3db -[NSApplication run] + 926
24  org.chromium.ContentShell.framework   0x00000001157321d7 0x1131fd000 + 39014871
25  org.chromium.ContentShell.framework   0x00000001157307fe 0x1131fd000 + 39008254
26  org.chromium.ContentShell.framework   0x000000011572d2a9 0x1131fd000 + 38994601
27  org.chromium.ContentShell.framework   0x0000000115758098 0x1131fd000 + 39170200
28  org.chromium.ContentShell.framework   0x00000001153cd5c3 0x1131fd000 + 35456451
29  org.cef.cefsimple                0x000000010caca449 CefRunMessageLoop() + 9 (libcef_dll_wrapper.cc:413)
30  org.cef.cefsimple                0x000000010c9ca1fa main + 1354 (cefsimple_mac.mm:139)
31  libdyld.dylib                    0x00007fffc138b235 start + 1

.... and more threads ....
Last edited by gabyx on Mon Feb 26, 2018 5:38 pm, edited 1 time in total.
gabyx
Newbie
 
Posts: 7
Joined: Sat Jan 13, 2018 9:06 am

Re: CEF macOS 12.10 and 10.11

Postby magreenblatt » Fri Feb 23, 2018 12:04 pm

gabyx wrote:I modified the original cef-simple executable to exactly use the same flags as I use for my app (see the crash dump)

What modifications specifically? Are you saying that these modifications compile/run fine on 10.11 but not 10.12.6? What Xcode version are you using to build on each macOS version?

It would also be helpful if you could provide a symbolized stack trace. Symbols are available from the same place that you downloaded the binary distribution.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: CEF macOS 12.10 and 10.11

Postby gabyx » Mon Feb 26, 2018 5:22 pm

That would be awesome, I try to get a symbolized output, in the next day on the computer which produced it.
We used on this Mac -> XTool 9.3 I think.

What I changed was, that I do not set the flags for the executable like in the `SET_LIBRARY_TARGET_PROPERTIES` function does in cef_macros.cmake for the `cef-simple`.
Actually cef-simple runs without setting any flags (calling SET_LIBRARY_TARGET_PROPERTIES) on my os 10.11.

I set my own flags: meaning the ones below:

Code: Select all
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR
       CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
        message(STATUS "Setting Compile/Linker Options for Clang")
        list(APPEND CXX_FLAGS_DEBUG "-fno-omit-frame-pointer"
                                    "-Wall"
                                    "-Wpedantic"
                                    "-Wno-documentation")

    elseif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
        list(APPEND CXX_FLAGS_DEBUG "-fno-omit-frame-pointer"
                                    "-Wall"
                                    "-Wpedantic"
                                    "-Wno-documentation")
    elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL "MSVC")
        message(ERROR "MSVC is not yet supported!")
    endif()


    if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
        # with clang 5.0.1: -fsanitize=address produces weird output in lldb for std::string ...
        list(APPEND CXX_FLAGS_DEBUG "-fsanitize=address" "-fsanitize=leak")
        set(LINKER_FLAGS "${LINKER_FLAGS} -fsanitize=leak -fsanitize=address -lc++experimental")
    elseif(CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
        list(APPEND CXX_FLAGS_DEBUG "-fsanitize=address")
        set(LINKER_FLAGS "${LINKER_FLAGS} -fsanitize=address -lc++experimental")
    elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL "MSVC")
        message(ERROR "MSVC is not yet supported!")
    endif()

    target_compile_features(${target} PUBLIC cxx_std_17)

    # Compile flags.
    target_compile_options(${target} PRIVATE $<$<CONFIG:Debug>:${CXX_FLAGS_DEBUG}> )

    # Linker flags.
    set_property(TARGET ${target} PROPERTY LINK_FLAGS ${LINKER_FLAGS})


    if(OS_MACOSX)
        set_target_properties(${target} PROPERTIES
            OSX_ARCHITECTURES_DEBUG      "${CMAKE_OSX_ARCHITECTURES}"
            OSX_ARCHITECTURES_RELEASE    "${CMAKE_OSX_ARCHITECTURES}"
        )
    endif()
gabyx
Newbie
 
Posts: 7
Joined: Sat Jan 13, 2018 9:06 am

Re: CEF macOS 12.10 and 10.11

Postby gabyx » Wed Feb 28, 2018 4:18 pm

OK, I found out that the whole thing works if I disable --fsanitize=address and --fsanitze=leak
meaning with clang 7.0.0 there is probbably some bug in the address sanitizer or something, which causes the malloc to fail.
Disabling these sanitizers with clang 7.0 helped.

I will report back if clang 6.0 rc2 also has the same problem...
gabyx
Newbie
 
Posts: 7
Joined: Sat Jan 13, 2018 9:06 am


Return to CEF Discussion

Who is online

Users browsing this forum: No registered users and 21 guests