FL_Native_File_Chooser crashing on show()

[rs]

Hi all,

I’m experiencing some weird behaviour with Fl_native_file_chooser in MacOS 15.4 with FLTK v1.4.2 , installed on my machine using CMake (i.e. cmake .. && make && make install)

Essentially, calling ->show()  for the native file chooser causes my program to crash

What is a bit strange, is that an old binary executable of my project that used to work, now no longer works, and currently exhibits this crashing behaviour. In the interim I have upgraded my version of MacOS so this might have something to do with it.

However, the test example associated to native-filechooser.cxx bundled with FLTK works fine.

After a bit of digging I have found that I only get the problem when I build my project with CMake as installed on my machine.

I can make this explicit, and illustrate what I mean, by treating the test app native-filechooser.cxx that ships with FLTK as a minimal example, contrasting what works for me and what does not.

Working Example 1:

If I compile native-filechooser.cxx with the following command

g++ native-filechooser.cxx `fltk-config  --ldstaticflags` -o test

Everything works as intended. In this case the fltk-config script returns “/usr/local/lib/libfltk.a -lm -lpthread -framework Cocoa -weak_framework ScreenCaptureKit -weak_framework UniformTypeIdentifiers”

Non-working Example 2:

If I create a CMakeLists.txt file as follows:

cmake_minimum_required(VERSION 3.15)
set(EXEC_NAME test)
project(${EXEC_NAME})
set(SRCS ./native-filechooser.cxx)
add_executable(${EXEC_NAME} WIN32 MACOSX_BUNDLE ${SRCS})
find_package(FLTK REQUIRED NO_MODULE)
target_include_directories(${EXEC_NAME} PUBLIC ${FLTK_INCLUDE_DIRS})
target_link_libraries(${EXEC_NAME} fltk)

and build it in the normal way (i.e. mkdir build && cd build && cmake .. && make)
then calling ->show() causes the native-filechooser.cxx example program to crash

A backtrace of the error looks like this (with the ->show() call in frame 14):

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x0000000182024388 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x000000018205d88c libsystem_pthread.dylib`pthread_kill + 296
    frame #2: 0x0000000181f66c60 libsystem_c.dylib`abort + 124
    frame #3: 0x000000018201339c libc++abi.dylib`abort_message + 132
    frame #4: 0x0000000182001d0c libc++abi.dylib`demangling_terminate_handler() + 344
    frame #5: 0x0000000181c88d74 libobjc.A.dylib`_objc_terminate() + 156
    frame #6: 0x00000001820126b0 libc++abi.dylib`std::__terminate(void (*)()) + 16
    frame #7: 0x0000000182015c48 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88
    frame #8: 0x0000000182015bf0 libc++abi.dylib`__cxa_throw + 92
    frame #9: 0x0000000181c7ecc8 libobjc.A.dylib`objc_exception_throw + 448
    frame #10: 0x0000000183401168 Foundation`-[NSString initWithUTF8String:] + 244
    frame #11: 0x00000001000cc518 test`createPopupAccessory(NSSavePanel*, char const*, char const*, int) + 1028
    frame #12: 0x00000001000ca974 test`Fl_Quartz_Native_File_Chooser_Driver::post() + 1200
    frame #13: 0x00000001000ca4b0 test`Fl_Quartz_Native_File_Chooser_Driver::show() + 36
    frame #14: 0x000000010004db28 test`Fl_Native_File_Chooser::show() + 56
    frame #15: 0x0000000100003fe0 test`PickFile_CB(Fl_Widget*, void*) + 152
    frame #16: 0x0000000100087b08 test`Fl_Widget::do_callback(Fl_Widget*, void*, Fl_Callback_Reason) + 100
    frame #17: 0x0000000100006e68 test`Fl_Widget::do_callback(Fl_Callback_Reason) + 40
    frame #18: 0x0000000100012678 test`Fl_Button::handle(int) + 848
    frame #19: 0x0000000100006f98 test`send_event(int, Fl_Widget*, Fl_Window*) + 292
    frame #20: 0x00000001000068b0 test`Fl::handle_(int, Fl_Window*) + 944
    frame #21: 0x00000001000064e8 test`Fl::handle(int, Fl_Window*) + 76
    frame #22: 0x00000001000bb01c test`cocoaMouseHandler(NSEvent*) + 1692
    frame #23: 0x00000001000bd764 test`-[FLView mouseUp:] + 32
    frame #24: 0x000000018695c6e8 AppKit`_routeMouseUpEvent + 132
    frame #25: 0x0000000185ebfb48 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 440
    frame #26: 0x0000000185ebf7c8 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 288
    frame #27: 0x0000000186735a54 AppKit`-[NSApplication(NSEventRouting) sendEvent:] + 1504
    frame #28: 0x00000001000ba970 test`+[FLApplication sendEvent:] + 368
    frame #29: 0x00000001000b7f24 test`do_queued_events(double) + 252
    frame #30: 0x00000001000b7ce4 test`Fl_Darwin_System_Driver::wait(double) + 204
    frame #31: 0x0000000100005364 test`Fl::wait(double) + 36
    frame #32: 0x00000001000053a4 test`Fl::run() + 52
    frame #33: 0x0000000100004884 test`main + 1296
    frame #34: 0x0000000181cbeb4c dyld`start + 6000

I’m guessing that I have broken something to do with the FLTK CMake installation setup, but I’m not sure how to diagnose/fix it and so would appreciate any suggestions.

Thanks,

R.

[Greg Ercolano]

I’m experiencing some weird behaviour with Fl_native_file_chooser in MacOS 15.4 with FLTK v1.4.2 , installed on my machine using CMake (i.e. cmake .. && make && make install)

Essentially, calling ->show()  for the native file chooser causes my program to crash

What is a bit strange, is that an old binary executable of my project that used to work, now no longer works, and currently exhibits this crashing behaviour. In the interim I have upgraded my version of MacOS so this might have something to do with it.

However, the test example associated to native-filechooser.cxx bundled with FLTK works fine.

After a bit of digging I have found that I only get the problem when I build my project with CMake as installed on my machine.

    OK, sounds like you've used the fltk test program, which builds fine when part of FLTK,
    but doesn't when you make your own cmake files and try to build (it crashes).

    What I would do is turn on the cmake flag that shows the compiler/link command lines
    when FLTK builds the app vs. when your cmake file builds it, and carefully compare.

    My guess is your cmake is building the app in a way that's referencing competing
    include files or libs.

    A common issue to check is to see if /usr/include/FL exists and if so, is pointing
    to the wrong place, as a command like #include <FL/xyz> will first look to /usr/include/FL/

    and if nothing is found there, falls back to the -I<somepath> compiler flags.

Non-working Example 2:

If I create a CMakeLists.txt file as follows:

cmake_minimum_required(VERSION 3.15)
set(EXEC_NAME test)
project(${EXEC_NAME})
set(SRCS ./native-filechooser.cxx)
add_executable(${EXEC_NAME} WIN32 MACOSX_BUNDLE ${SRCS})
find_package(FLTK REQUIRED NO_MODULE)
target_include_directories(${EXEC_NAME} PUBLIC ${FLTK_INCLUDE_DIRS})
target_link_libraries(${EXEC_NAME} fltk)

    I'm no cmake expert (that'd be Albrecht), but I think there you're using find_package()
    which is going to use whatever FLTK cmake config is in the path that cmake checks
    for packages.

    If you have multiple installs of FLTK on the machine, you may need to force it
    to look in a particular directory, and I think you can do that by adding an absolute
    path to the find_package() command. I had to do that recently, and used (in my case
    with an FLTK "non-installed" build directory being /usr/local/src/fltk-1.5.x.git/build):

find_package(FLTK    REQUIRED
             PATHS /usr/local/src/fltk-1.5.x.git/build
             NO_MODULE CONFIG)

    I kept the line breaks in the command just as shown; three lines total.

    I don't know if that's precisely correct, but "it worked" for me.
    Without that, cmake couldn't find the FLTKConfig.cmake file that
    gets created when FLTK is configured by cmake.

[Greg Ercolano]

    What I would do is turn on the cmake flag that shows the compiler/link command lines
    when FLTK builds the app vs. when your cmake file builds it, and carefully compare.

    To enable showing compile/link commands, apparently this can be done on the
    make command line, e.g.

        make VERBOSE=on

    I think cmake sets the Makefile up this way, so it should work for both
    building FLTK and building your app so you can see and compare.

    The one thing this won't show in the compiler/link commands is if
    /usr/include/FL is causing the trouble, so check that first.

    If my /usr/include directory has an FL subdir or link, and I don't
    want crosstalk between different versions of FLTK on my machine,
    I usually rename /usr/include/FL away, so that I have to point my app's
    builds directly to a specific FLTK version, including the #include paths.
    Doing so avoids the weird crashes you can get when the #include files dont
    match the FLTK libs being linked.

[rs]

Ok, I've uninstalled FLTK on my system (i.e. from /usr/local using make uninstall from the build dir) and then rebuilt it from scratch locally within fltk-1.4.2/build as you suggested. I've then used

find_package(FLTK    REQUIRED
             PATHS ~/src/fltk-1.4.2/build
             NO_MODULE CONFIG)

in CMakeLists.txt, pointing at my local copy of FLTK.

I've then confirmed in the CMake files that the -I and -L (include and link) paths are indeed using my local copy.

But I still get the same behaviour: it crashes when I build with CMake.

I'm now going to see examine the verbose output of building the example vs my version built with CMake...

[Greg Ercolano]

On 4/8/25 5:13 PM, rs wrote:

But I still get the same behaviour: it crashes when I build with CMake.

    Be sure to check that /usr/include/FL does not exist.
    If it does rename it away, as that's often a cause.

[rs]

Yep, I've made sure /usr/include/FL is not there (I manually deleted it after uninstalling FLTK)

I've got the relevant verbose output from the two different cases now:

The working version compiled as part of the bundled tests shipped with FLTK has these compile and link steps:

/usr/bin/c++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -Dnative_filechooser_EXPORTS -I/Users/xxx/src/fltk-1.4.2/zlib -I/Users/xxx/src/fltk-1.4.2/png -I/Users/xxx/src/fltk-1.4.2/jpeg -I/Users/xxx/src/fltk-1.4.2/build/test -I/Users/xxx/src/fltk-1.4.2/test -I/Users/xxx/src/fltk-1.4.2/build/src/.. -I/Users/xxx/src/fltk-1.4.2/src/.. -Wno-deprecated -arch arm64 -MD -MT test/CMakeFiles/native-filechooser.dir/native-filechooser.cxx.o -MF CMakeFiles/native-filechooser.dir/native-filechooser.cxx.o.d -o CMakeFiles/native-filechooser.dir/native-filechooser.cxx.o -c /Users/xxx/src/fltk-1.4.2/test/native-filechooser.cxx

/usr/bin/c++  -Wno-deprecated -arch arm64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names "CMakeFiles/native-filechooser.dir/native-filechooser.cxx.o" -o ../bin/test/native-filechooser.app/Contents/MacOS/native-filechooser   -L/Users/xxx/src/fltk-1.4.2/build/src/../lib  -Wl,-rpath,/Users/xxx/src/fltk-1.4.2/build/src/../lib ../lib/libfltk_images.a ../lib/libfltk.a -framework Cocoa -weak_framework ScreenCaptureKit -weak_framework UniformTypeIdentifiers /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libdl.tbd ../lib/libfltk_png.a ../lib/libfltk_z.a ../lib/libfltk_jpeg.a

The non-working version compiled with my CMakeLists.txt modifed to point to src/fltk-1.4.2/build has these compile and link steps:

/usr/bin/c++  -I/Users/xxx/src/fltk-1.4.2/build -I/Users/xxx/src/fltk-1.4.2 -isystem /Users/xxx/src/fltk-1.4.2/build/src/.. -isystem /Users/xxx/src/fltk-1.4.2/src/.. -arch arm64 -MD -MT CMakeFiles/test.dir/native-filechooser.cxx.o -MF CMakeFiles/test.dir/native-filechooser.cxx.o.d -o CMakeFiles/test.dir/native-filechooser.cxx.o -c /Users/xxx/scratch/fltk_test/native-filechooser.cxx

/usr/bin/c++  -arch arm64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names "CMakeFiles/test.dir/native-filechooser.cxx.o" -o test.app/Contents/MacOS/test   -L/Users/xxx/src/fltk-1.4.2/build/src/../lib  -Wl,-rpath,/Users/xxx/src/fltk-1.4.2/build/src/../lib /Users/xxx/src/fltk-1.4.2/build/lib/libfltk.a -framework Cocoa -weak_framework ScreenCaptureKit -weak_framework UniformTypeIdentifiers /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libdl.tbd

The only differences I can see are that: 

the working version includes these flags at the compile stage:

D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE

and it also links to:

../lib/libfltk_png.a ../lib/libfltk_z.a ../lib/libfltk_jpeg.a

The non-working version also includes a flag -isystem

I'll keep digging for now.

R.

[rs]

Whatever the issue is I don't think it lies in those compile and link commands, but in something else that CMake is doing.

Explicitly, I copied the compile and link commands that resulted from my CMakeLists.txt file (and which generated a crashing binary when running cmake .. && make) reported above, but it leads to a binary that *doesn't* crash. I.e. I can only get the crashing behaviour when I run through  the usual cmake commands to build the program (mkdir build && cd build && cmake .. && make).

So the culprit might be somewhere in the result of running 'make VERBOSE=on'  which looks like this

make VERBOSE=on
/opt/homebrew/bin/cmake -S/Users/xxx/scratch/fltk_test -B/Users/xxx/scratch/fltk_test/build --check-build-system CMakeFiles/Makefile.cmake 0
/opt/homebrew/bin/cmake -E cmake_progress_start /Users/xxx/scratch/fltk_test/build/CMakeFiles /Users/xxx/scratch/fltk_test/build//CMakeFiles/progress.marks
/Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/Makefile2 all
/Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
cd /Users/xxx/scratch/fltk_test/build && /opt/homebrew/bin/cmake -E cmake_depends "Unix Makefiles" /Users/xxx/scratch/fltk_test /Users/xxx/scratch/fltk_test /Users/xxx/scratch/fltk_test/build /Users/xxx/scratch/fltk_test/build /Users/xxx/scratch/fltk_test/build/CMakeFiles/test.dir/DependInfo.cmake "--color="
/Library/Developer/CommandLineTools/usr/bin/make  -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
[ 50%] Building CXX object CMakeFiles/test.dir/native-filechooser.cxx.o
/usr/bin/c++  -I/Users/xxx/src/fltk-1.4.2/build -I/Users/xxx/src/fltk-1.4.2 -isystem /Users/xxx/src/fltk-1.4.2/build/src/.. -isystem /Users/xxx/src/fltk-1.4.2/src/.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -arch arm64 -MD -MT CMakeFiles/test.dir/native-filechooser.cxx.o -MF CMakeFiles/test.dir/native-filechooser.cxx.o.d -o CMakeFiles/test.dir/native-filechooser.cxx.o -c /Users/xxx/scratch/fltk_test/native-filechooser.cxx
[100%] Linking CXX executable test.app/Contents/MacOS/test
/opt/homebrew/bin/cmake -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=on
/usr/bin/c++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -arch arm64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names "CMakeFiles/test.dir/native-filechooser.cxx.o" -o test.app/Contents/MacOS/test   -L/Users/xxx/src/fltk-1.4.2/build/src/../lib  -Wl,-rpath,/Users/xxx/src/fltk-1.4.2/build/src/../lib /Users/xxx/src/fltk-1.4.2/build/lib/libfltk.a -framework Cocoa -weak_framework ScreenCaptureKit -weak_framework UniformTypeIdentifiers /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libdl.tbd
[100%] Built target test
/opt/homebrew/bin/cmake -E cmake_progress_start /Users/xxx/scratch/fltk_test/build/CMakeFiles 0

If I copy these commands and run them manually I get a program that crashes. So the problem is somewhere in these commands or in the result of running 'cmake ..'

[Greg Ercolano]

On 4/8/25 7:23 PM, rs wrote:

[..]

So the culprit might be somewhere in the result of running 'make VERBOSE=on'  which looks like this

    Sounds like you're on the right road at least  to figuring it out, since it sounds like you now have commands that work vs commands that fail.

    You can probably narrow it down by organizing the two sets of build commands into separate scripts, and carefully run them side by side carefully merging bits from the working one into the broken one until you find the culprit.

    Note that on macs, besides compile + link, GUIs need that ".app" directory structure whose contents includes not only the binary, but a plist + resource file or some such that I suppose could cause a crash if malformed. I usually use "fltk-config --post" to apply that stuff to convert the binary into a .app package. Maybe that step is getting missed or is being mis-created?

    Perhaps others will see the problem in all your output; I'm not used to all that noise from cmake, as I build my cross platform projects using old school Makefiles that employ "fltk-config" to do most of the work creating the correct compiler/link flags.

[rs]

So it turns out the app bundle is the problem. 

If I run the program from within the bundle it crashes. 

If I copy the program from 'test.app/Contents/MacOS/test' to another location and run it as a simple command line program, it runs fine.

Testing further it seems that the problem is with the 'test.app/Contents/Info.plist' file --- if I simply delete it then the program doesn't crash.

There is an Info.plist in the bundled native-filechooser.app which does run.

So I compare them and the critical difference appears to be on these two lines:

Runs:

        <key>CFBundleIdentifier</key>
<string>test</string>

Crashes:

        <key>CFBundleIdentifier</key>
<string></string>

I am completely mystified as to why this causes this crashing behaviour, but the minimal CMakeLists.txt file above certainly didn't set it.

The overall story that fits what I've experienced (whereby an old version of my project, which previously ran fine, but crashes now) is that with the upgrade to MacOS 15.4 an app bundle must populate the CFBundleIdentifier field or it will not run properly, meanwhile my CMakeLists.txt had not specified it.

So I now include the following in my CMakeLists.txt file:

set_target_properties(${EXEC_NAME} PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER "org.programname")

for example, and my project is running crash free once more.

This was a painful one.

Thanks for the help.

R.

[Greg Ercolano]

On 4/9/25 1:00 AM, rs wrote:

So it turns out the app bundle is the problem. 

[..]

Runs:

        <key>CFBundleIdentifier</key>
<string>test</string>

Crashes:

        <key>CFBundleIdentifier</key>
<string></string>

I am completely mystified as to why this causes this crashing behaviour, but the minimal CMakeLists.txt file above certainly didn't set it.

    Yeah, that's a Mac thing, all mac guis have to have that .app directory "just so" or the app can behave strangely.
    I never understood why it's so damn important but it is. Might have to do with how the app registers itself with the OS to show icons and such, and on Macs icons are very important.

    I kinda like the .app concept, as it keeps all the app's data organized in a standardized directory structure, but it seems a bit brittle.

[Jose Quinteiro]

Contrast with the Windows Registry where all apps settings are dumped
into one great big tree. Both approaches have advantages and
disadvantages. I personally prefer the MacOS (which is really NeXT)
approach, but I don't use that platform any more.

Thanks,
Jose

> --
> You received this message because you are subscribed to the Google
> Groups "fltk.general" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fltkgeneral...@googlegroups.com
> <mailto:fltkgeneral...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> fltkgeneral/f87e1071-29b8-43fd-b6f8-120235918e33%40seriss.com <https://
> groups.google.com/d/msgid/fltkgeneral/f87e1071-29b8-43fd-
> b6f8-120235918e33%40seriss.com?utm_medium=email&utm_source=footer>.