Mac: Thread trace is printing to the terminal when GLFW app is made fullscreen

Hello!

I’ve been a long-time fan of GLFW but this is my first time making a forum post. I’ve been working on a Vulkan application on Mac using GLFW, and tonight I noticed some strange output being printed to the terminal that I hadn’t seen before. This is just an excerpt, but it was something like this, and it appeared to be a trace of what the app’s thread was doing when the window is being resized:

30 libglfw.3.3.dylib 0x0000000100c03610 glfwPollEvents + 48
31 output 0x00000001009363bc _ZN7display6updateEv + 56
32 output 0x0000000100940c18 main + 7280
33 dyld 0x00000001ae11be50 start + 2544

I can provide the rest of the output in a reply as well, I just left it off here for brevity.

It only happened when the app was maximized into fullscreen mode using the green menu bar button, and with some print statement debugging, it seems like it’s happening the next time glfwPollEvents() is called after going to fullscreen mode.

My code had been using 3.3.7, but I tried 3.3.8 as well and was getting the same results. I’m also using MacOS 13.1, so I didn’t know if Apple made some change to their internal APIs to make this info print out. I’ve never seen this output before, but it has also been a few weeks since I’d last worked on the project.

There wasn’t any kind of crash though, the app ran normally, there were no crash logs in the console, other than the extra output everything seemed to run normally.

Does anyone know if this is a bug with GLFW or with MacOS? Or is this kind of output to be expected due to a recent API change? Any help would be greatly appreciated, thank you for taking the time to read this!

Hi @Muketsu,

Welcome to the GLFW forum!

GLFW itself doesn’t print anything (though many of the examples do). It does have an error callback and description string which are created with vsnprintf but this doesn’t output to console unless your application redirects it.

This does look like a callstack, though as to why it’s being output I don’t know. Does this happen with a simple minimal example such as triangle-vulkan.c modified to switch to fullscreen?

You mentioned that this only a excerpt - glfwPollEvents is pretty high level, do you have the rest of the stack above this? I presume you can see _glfwPollEventsCocoa as this is what it calls, but the rest may give us a clue as to what’s going on.

If you have any callbacks set then these will likely be called during glfwPollEvents, and one of these could be printing the stack. If you’re using any libraries in the callbacks it might be worth checking if they print to console, or putting breakpoints/printf debugging around the callbacks to check if one of these is the culprit.

Cheers,

Doug.

Thank you very much for the fast reply!

I hadn’t thought to test a separate triangle application, so that was the first thing I did today. I tested a simple Vulkan triangle app, using the code on vulkan-tutorial.com as a baseline, and was still seeing the same output. The simple triangle wasn’t using any libraries other than GLFW and Vulkan, and I also tested it without any GLFW callbacks set in the code, so it may be OS related? I can’t quite tell what the trace is reporting, but I’ll past the full text here:

1 HIToolbox 0x00000001b7c6c5c8 _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 120
2 HIToolbox 0x00000001b7c6c188 _ZN15MenuBarInstance14EnableAutoShowEv + 60
3 HIToolbox 0x00000001b7bd98bc _ZN15MenuBarInstance21UpdateAggregateUIModeE21MenuBarAnimationStylehhh + 1184
4 HIToolbox 0x00000001b7c6c004 _ZN15MenuBarInstance19SetFullScreenUIModeEjj + 180
5 AppKit 0x00000001b1a62008 -[NSApplication _setPresentationOptions:instance:flags:] + 956
6 AppKit 0x00000001b18f7bb0 -[NSApplication _updateFullScreenPresentationOptionsForInstance:] + 404
7 CoreFoundation 0x00000001ae519570 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148
8 CoreFoundation 0x00000001ae5b7054 ___CFXRegistrationPost_block_invoke + 88
9 CoreFoundation 0x00000001ae5b6f9c _CFXRegistrationPost + 440
10 CoreFoundation 0x00000001ae4eab74 _CFXNotificationPost + 708
11 Foundation 0x00000001af3d872c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
12 AppKit 0x00000001b1a6258c spacesNotificationHandler + 96
13 SkyLight 0x00000001b314c4dc ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1 + 896
14 SkyLight 0x00000001b34784c4 _ZN21CGSDatagramReadStream26dispatchMainQueueDatagramsEv + 228
15 SkyLight 0x00000001b34783c0 ___ZN21CGSDatagramReadStream15mainQueueWakeupEv_block_invoke + 28
16 libdispatch.dylib 0x00000001ae2bc9dc _dispatch_call_block_and_release + 32
17 libdispatch.dylib 0x00000001ae2be504 _dispatch_client_callout + 20
18 libdispatch.dylib 0x00000001ae2ccd1c _dispatch_main_queue_drain + 928
19 libdispatch.dylib 0x00000001ae2cc96c _dispatch_main_queue_callback_4CF + 44
20 CoreFoundation 0x00000001ae565d50 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
21 CoreFoundation 0x00000001ae5237d0 __CFRunLoopRun + 2036
22 CoreFoundation 0x00000001ae522888 CFRunLoopRunSpecific + 612
23 HIToolbox 0x00000001b7bf7fa0 RunCurrentEventLoopInMode + 292
24 HIToolbox 0x00000001b7bf7de4 ReceiveNextEventCommon + 672
25 HIToolbox 0x00000001b7bf7b2c _BlockUntilNextEventMatchingListInModeWithFilter + 72
26 AppKit 0x00000001b17a4424 _DPSNextEvent + 632
27 AppKit 0x00000001b17a35b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728
28 libglfw.3.3.dylib 0x0000000102c1edd8 _glfwPlatformPollEvents + 152
29 libglfw.3.3.dylib 0x0000000102c17610 glfwPollEvents + 48
30 a.out 0x0000000102ae1cf4 _ZN24HelloTriangleApplication8mainLoopEv + 52
31 a.out 0x0000000102ae0eb8 _ZN24HelloTriangleApplication3runEv + 44
32 a.out 0x0000000102ae0bd8 main + 616
33 dyld 0x00000001ae11be50 start + 2544

Thanks for your help!

I can’t see anything in this callstack which points a finger at anything. I’m wonder if MenuBarInstance22EnsureAutoShowObserverEv at the top calls into user code, and that this is what dumps the callstack.

Have you tried this on another Mac? I’m wondering if there is something installed on your machine which causes this - we’ve seen issues with a plugin on Windows which injects itself into the OpenGL driver for example. It might also be worth checking if updating or changing the Vulkan SDK you are building against or the MoltenVK library changes anything.

It’s also worth while checking if you have the Vulkan Configurator set to add any validation layers or if you have the VK_INSTANCE_LAYERS environment variable set.

If I get time later on I’ll do some testing on my Mac, but I’m on High Sierra since it’s an older machine and need to reinstall all my dev tools since the hard disk died recently so this will take me some time.

I only have one Mac myself, so I haven’t been able to test on another one yet. I’m asking a couple of friends who have one though, so I’m hoping I can test on another one later today. If I am able to, I’ll report back with what happens.

I was able to try with an older OpenGL engine I was working on, however, and it did the same thing with GLFW 3.3.5. So at the very least, it seems like it doesn’t matter which version of GLFW it is, as long as it works with M1 chips, and it also doesn’t seem to be related to Vulkan.

I can’t think of anything I would have installed recently that would cause this behavior, but hopefully if I’m able to test on another machine, that might shed some light on it. The only thing I can think of that’s recently changed about my system was updating to 13.1 this week. It’s hard to tell what might be related though, because I don’t often test out the fullscreen mode with this code, so I can’t pinpoint exactly when this might’ve started happening.

Thanks again for your help! And I’ll post again if I’m able to test out another Mac

I was able to test on another Mac, and got pretty interesting results. I know someone with another M1-based Mac that was running MacOS 12.x, and upon first testing, the stack dump wasn’t appearing.

This person was willing to update, however, and once the machine was updated to 13.1, the stack dump began appearing exactly as it has been on my machine.

I’m not familiar enough with Mac API calls to have any idea what the root cause might be, but it does seem to be tied to some change made in MacOS itself, since the MacOS version was the only difference between the two tests on my friend’s machine, and it did affect whether the stack dump printed.

If there’s any other testing I can do that might be helpful, I’d be happy to, and again I really appreciate your help with this!

That’s really interesting! Thanks for the further testing.

Is this only being shown when launched from a console or does it show if launched from Finder or the toolbar? Normally apps launched from the GUI don’t open up a console, so I’m guessing this is only when launched from console.

I don’t know what has been changed in MacOS X to cause this, and it looks like an OS issue rather than one with GLFW, but it’s probably worth reporting as an issue on Github with a link to the information here. If you don’t have an account there I can report it.

No problem! I’m only noticing it in a terminal window. If I run the code directly from the terminal, I’ll see it. I’ll also see it if I double-click run one of my executables from Finder, since they open a terminal window to run. I did also test some of the included GLFW examples apps, and since those didn’t open terminal windows, I wasn’t seeing any of the trace output. It may still be happening in a less-visible way, but I don’t have too much experience building and running programs outside of a terminal.

I also went ahead and made a Github issue report! It’s the first issue report I’ve made on there, so please let me know if anything needs to be changed or added, or if there’s any other testing I can do.

Thanks again!

Thanks - the report is excellent.I would recommend pasting text rather than images for text in future as you can’t copy-paste the text from an image to search for it!