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:
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!
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.
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:
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 Configuratorset 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 - 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!