Reading osx crash report

I’m having some clients who are using intel based Macbooks. My app works fine on all other macbooks I have tested it on (including M1 systems) but these guys are getting strange errors. They sent me a crash report and it seems to be pointing to the GLFWsetwindowtitle, is that correct? I am not sure how to read these reports exactly.

Process: myappv1.0 [603]
Path: /Applications/
Identifier: org.example.Scratch-visualizer
Version: 1.1 (1.0.0)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-07-07 11:40:40.5412 +0100
OS Version: macOS 12.4 (21F79)
Report Version: 12
Anonymous UUID: 3565F604-296F-C0BE-6D63-EC2C19B9162E
Time Awake Since Boot: 110 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue:
0 libsystem_kernel.dylib 0x7ff81c65c00e __pthread_kill + 10
1 libsystem_pthread.dylib 0x7ff81c6921ff pthread_kill + 263
2 libsystem_c.dylib 0x7ff81c5ddd24 abort + 123
3 libsystem_c.dylib 0x7ff81c5dd0cb __assert_rtn + 314
4 myappv1.0 0x10338cce2 glfwSetWindowShouldClose + 82
5 myappv1.0 0x102b8a608 ofMainLoop::shouldClose(int) + 76
6 myappv1.0 0x102b9273e (anonymous namespace)::ofSignalHandler(int) + 322
7 libsystem_platform.dylib 0x7ff81c6a7dfd _sigtramp + 29
8 ??? 0x4 ???
9 libsystem_c.dylib 0x7ff81c5ddd24 abort + 123
10 libsystem_c.dylib 0x7ff81c5dd0cb __assert_rtn + 314
11 myappv1.0 0x10338cd73 glfwSetWindowTitle + 83
12 myappv1.0 0x102b93be7 ofSetWindowTitle(std::__1::basic_string<char, std::__1::char_traits,
std::__1::allocator >) + 71
13 myappv1.0 0x102b19c6f ofApp::setup() + 127
14 myappv1.0 0x102b58829
std::__1::__function::__func<std::__1::shared_ptr<of::priv::Function<glm::vec<3, float, (glm::qualifier)0>,
std::__1::recursive_mutex> > ofEvent<glm::vec<3, float, (glm::qualifier)0>, std::__1::recursive_mutex>::make_function
(ofNode*, void (ofNode::)(glm::vec<3, float, (glm::qualifier)0>&), int)::‘lambda’(void const, glm::vec<3, float, (glm::qualifier)0>&),
std::__1::allocator<std::__1::shared_ptr<of::priv::Function<glm::vec<3, float, (glm::qualifier)0>, std::__1::recursive_mutex> >
ofEvent<glm::vec<3, float, (glm::qualifier)0>, std::__1::recursive_mutex>::make_function(ofNode*, void (ofNode::)
(glm::vec<3, float, (glm::qualifier)0>&), int)::‘lambda’(void const
, glm::vec<3, float, (glm::qualifier)0>&)>, bool (void const*,
glm::vec<3, float, (glm::qualifier)0>&)>::operator()(void const*&&, glm::vec<3, float, (glm::qualifier)0>&) + 37
15 myappv1.0 0x102b56ccf std::__1::function<bool (void const*, glm::vec<3, float,
(glm::qualifier)0>&)>::operator()(void const*, glm::vec<3, float, (glm::qualifier)0>&) const + 31
16 myappv1.0 0x102bf3906 ofEvent<ofEventArgs, std::__1::recursive_mutex>::notify(ofEventArgs&) + 134
17 myappv1.0 0x102b89f79 ofMainLoop::run(std::__1::shared_ptr,
std::__1::shared_ptr&&) + 1677
18 myappv1.0 0x102b929cf ofRunApp(std::__1::shared_ptr,
std::__1::shared_ptr&&) + 62
19 myappv1.0 0x102aea206 main + 1142
20 dyld 0x10ba3851e start + 462

it’s hard to tell from the crash report exactly – maybe this is helpful?

in general – when sharing Mac apps, you may want to look into signing the app, notarizing it and signing the disk image for distribution. I’m not sure if your app uses a data folder, but generally, I’ve run into many issues distributing Mac apps because of app translocation

my general work flow it so notarize apps I am sending to clients and use dmg canvas to make a signed dmg.

Hi Zach,

thanks for your response. I’ve struggled with the app translocation in the past - which is also why I am using the disk images. I’ve asked the user to copy the whole app to a different location, just to rule it out, but I don’t expect it to be the problem.

I’ve had other users who are also using intel based macs and, although they don’t experience crashing apps, their screens are looking very dodgy. No fonts, or way too larger fonts, and very odd screen sizes. I set them in the app to be e.g. a rectangle, but they show up as a big square, even ‘tabbed’ into one window. This leads me to suspect some kind of GLFW library issue, and I noticed there is some fixes for this in the 0.11.2 version - which I cannot get working as of yet…

so at this point I am trying to troubleshoot what I can with 0.11.0

Does that make sense?