skui-org / skui

Skia-based C++ UI framework

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`widget_gallery` segmentation fault on MacOS 10.13.6

JaimeIvanCervantes opened this issue · comments

commented

I know that MacOS 10.13.* is a TODO, but I tried to build on my MacOS 10.13.6 anyways. I was finally able to build with the following:

  • On path.h++, replaced <experimental/filesystem> with ghc::filesystem from https://github.com/gulrak/filesystem
  • Added SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.14") to the root CMakeLists.txt
  • Removed -lc++fs from core/CMakeLists.txt, because it was causing a linker error.

But now that I am trying to run widget_gallery I am getting a segfault, specifically on the line skui::gui::window window{{0,0}, {200, 200}}. Interestingly, all the tests are passing.

Here's the backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001000522a8 widget_gallery`skui::gui::window::window(this=0x00007ffeefbfeac8)::$_1::operator()() const at window.c++:67
   64  	    , position{position}
   65  	    , icon{}
   66  	    , title{[this](const core::string& title) { native_window->set_title(title); },
-> 67  	            [this] { return native_window->get_title(); }}
   68  	    , native_window{nullptr}
   69  	    , render_thread{}
   70  	    , render_loop{implementation::render_filter}
Target 0: (widget_gallery) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001000522a8 widget_gallery`skui::gui::window::window(this=0x00007ffeefbfeac8)::$_1::operator()() const at window.c++:67
    frame #1: 0x0000000100052264 widget_gallery`std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::__invoke_void_return_wrapper<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::__call<skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1&>(skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1&&&) [inlined] decltype(__f=0x00007ffeefbfeac8)::$_1&>(fp)(std::__1::forward<>(fp0))) std::__1::__invoke<skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1&>(skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1&&&) at type_traits:4428
    frame #2: 0x000000010005224f widget_gallery`std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::__invoke_void_return_wrapper<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::__call<skui::gui::window::window(__args=0x00007ffeefbfeac8)::$_1&>(skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1&&&) at __functional_base:318
    frame #3: 0x0000000100052150 widget_gallery`std::__1::__function::__func<skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1, std::__1::allocator<skui::gui::window::window(skui::graphics::position2D<int>, skui::graphics::size2D<unsigned long>, skui::core::bitflag<skui::gui::window_flag, 32ul>)::$_1>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > ()>::operator(this=0x00007ffeefbfeac0)() at functional:1562
    frame #4: 0x000000010005b675 widget_gallery`std::__1::function<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > ()>::operator(this=0x00007ffeefbfeac0)() const at functional:1913
    frame #5: 0x000000010005b05b widget_gallery`skui::core::proxy_property<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::operator std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >(this=0x00007ffeefbfe9c0) const at proxy_property.h++:87
    frame #6: 0x0000000100031db4 widget_gallery`skui::core::proxy_property<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::operator=(this=0x00007ffeefbfe9c0, other="Widget Gallery") at proxy_property.h++:67
    frame #7: 0x0000000100030ecf widget_gallery`skui::gui::window::window(this=0x00007ffeefbfe5c0, position=(x = 0, y = 0), initial_size=(width = 200, height = 200), flags=skui::gui::window_flags @ 0x00007ffeefbfdf40) at window.c++:81
    frame #8: 0x0000000100032485 widget_gallery`skui::gui::window::window(this=0x00007ffeefbfe5c0, position=(x = 0, y = 0), initial_size=(width = 200, height = 200), flags=skui::gui::window_flags @ 0x00007ffeefbfe4c0) at window.c++:74
    frame #9: 0x000000010000693d widget_gallery`main(argc=1, argv=0x00007ffeefbff928) at widget_gallery.c++:123
    frame #10: 0x00007fff5b34d015 libdyld.dylib`start + 1
    frame #11: 0x00007fff5b34d015 libdyld.dylib`start + 1

Thanks for the information.
The native window/visual/... implementation is indeed missing and that is the cause of the segfault you see. The tests only test non-GUI code, so that explains what you notice there.
If you inspect the Travis yml file, you will see I build libc++ with filesystem support and use that. You should be able to run the libc++ build script on your Mac as well. Xcode releases unfortunately lag quite a bit behind with these c++17 features relative to upstream LLVM releases.
The native window/visual layer will probably best be implemented in Objective-C++, and help is definitely welcome. Basically what is needed is:

  • window creation and some simple things like setting the title, closing, etc.
  • OpenGL intialization. Currently the skui::opengl library isn't used for this, so just doing what the Windows/Linux code does for those platforms. Alternatively, implement blitting of a CPU based pixel buffer onto a Mac window.
  • combining these in a "visual" such that you can draw on the screen directly.

Note the full functionality of all this code is pretty limited and I am currently sidetracked on CSS parsing for UI styling and torn between writing an parser expression grammar library to use for that or keep fighting Boost Spirit X3.

Help is always welcome :).

commented

I didn't have time to delve into the code, and I made the assumption that there was already a window platform/native implementation for MacOS :P. Things have been a bit hectic lately, but I'll see if I can make some time to help. Perhaps it will useful to look at the imgui example for Apple: https://github.com/ocornut/imgui/blob/master/examples/example_apple_opengl2/main.mm#L158

With respect to the CSS parser, this is exactly what brought me to your project; I have been exploring the idea of using Spirit X3 to parse SVG (and CSS indirectly). I also thought about writing my own parser, but tbh, Spirit X3 is the 3rd generation of the Spirit parsers (~10 yrs of development), and to me it seems mature enough to be used in production. Also, the Spirit team is doing a great job answering questions on SO ;). Maybe it would be helpful to look at this CSS parser using the older Spirit: https://github.com/emweb/wt/blob/master/src/Wt/Render/CssParser.C

The older Spirit is not an option as X3 supposedly has superior performance (both compile time as runtime). It's either that or I get somewhere with my parsing library. My spare time is limited, and this really is currently my hobby project. I'm very curious where it all will end :)