freac
freac copied to clipboard
enzo1982
Crash under OS X 10.15.7
Describe the bug
Yesterday I updated my OS X to 10.15.7. I found fre:ac 1.1.2 crash when I try to click up-side-down triangle button at upper-right corner of every input box.
To Reproduce Steps to reproduce the behavior:
- Drag 2 or more file to main window
- Write something Within Artist or Album input box
- Move cursor to upper-right corner of the input box, the expected triangle button doesn't show up
- Click the area where the triangle should be, the application crash
Expected behavior It should shows a drop-down menu
System (please complete the following information)
- OS: macOS Catalina 10.15.7
- CPU: Intel Core i7 6 cores
- RAM: 16GB
- fre:ac: 1.1.2
Additional context It works just before I upgrade my OS. I'm not 100% sure this is due to OS upgrade, but highly doubtful.
Is there any log I can provide, or other I can help?
Is 1.1.3 about to release? I found it support Big Sur. Maybe 1.1.3 works well on 10.15.7?
Not found a pre-build version yet.
I just tried to reproduce this on macOS 10.15.7, but without success. The menu is working here without crashing.
So probably multiple things come together here to produce the crash. Did you try with different files?
1.1.3 will be released soon (possibly the coming weekend), but I doubt it would make a difference here.
I just tried to reproduce this on macOS 10.15.7, but without success. The menu is working here without crashing.
So probably multiple things come together here to produce the crash. Did you try with different files?
1.1.3 will be released soon (possibly the coming weekend), but I doubt it would make a difference here.
I tried again and found it intresting:
It only crashes on my extended monitor. Within the built-in display, it works OK.
So how can I dig into it? Build it myself and debug, or there's any crash log I can send?
I remember with OSX 10.15.5 and earlier, fre:ac 1.1.2 won't work well on second monitor. The triangle button is there, and able to click. But the drop-down menu is shown at right-down corner of the monitor. Maybe they're caused by a same bug, and it got worse with OSX 10.15.7.
OK, thanks for the update. This might well have something to do with the external monitor. Especially if it has a different scale factor than the main display.
I never tested with external displays on Mac. The necessary adapter is almost 80€, so that's a bit high just to try it. I'll see if I can find someone with an adapter or a USB-C monitor where I can test this.
As for crash logs, macOS usually displays a crash reporter dialog when an app crashes. If you could send me what is shown in the Details view, that might help. The information there is not always helpful, because the fre:ac release version comes without debug symbols, but sometimes it gives an idea of what's going wrong.
Other than that, if you are capable of building and debugging fre:ac yourself, that would of course be great.
There's no crash report. It just exit silently.
I have no expirence compiling a OS X project. Would you please give some short hint how to compile? What environment is needed and what should be taken care? Just some keyword is enough. Hope I can have some spare to check out.
If you are using a Mac with USB-C, a U-Green USB-C to DP adapter is nice. I'm using one and it works fine. It only costs about 10 EUR in China.
Alright, I ordered a USB-C to DP cable. I wasn't sure if those require Thunderbolt, but apparently not. I have the 2015 MacBook which only has a USB-C port without Thunderbolt support.
For building fre:ac on macOS, you need Xcode installed. Then there's a build script in the tools folder: build-freac
The script will check out, build and install three projects, the smooth class library, BoCA components and fre:ac itself. It will ask for your password on the install step and then install to /usr/local.
After that, you can run the prepare.sh script from the packaging/macosx folder. If all goes well, it will result in a working freac.app in that folder.
You might see some warnings about missing codecs when running the packaging script. Those are not strictly necessary - fre:ac will run without the codecs, but support less formats. If you want to build codecs, there is a build-codecs script in the tools folder. Support for recent releases of macOS is limited, though, so not all codecs will build.
The cable should arrive on Monday btw., so I think I'll delay the 1.1.3 release by a few days to see if I can include a fix.
2015 and later MBP intergrated USB-C and TB3 into same connector. You can use it as a USB-C or TB3 without any trouble. The PHY can switch automatically.
I'm trying build fre:ac. If I get any progress I'll contact ASAP.
I have the MacBook, though, not the MacBook Pro. The 2015 MacBook is the only Mac released after 2012 that does not support Thunderbolt.
Yo it's hard to get it work. libcdio-paranoia is not within homebrew, and I cannot swith to MacPort. So I manually compiled several dependencies and several basic codecs. My /usr/local is populated as mess. Maybe after this debugging, I should port libcdio-paranoia to homebrew.
The good news is the app is working now. But I cannot test with ext monitor cause it's 6 AM China and I have to sleep.
I'll do some test with LLDB hooked and see what happened inside.
I digged into the code a bit. I found in surfacecocoa.mm, the function "S::GUI::SurfaceCocoa::GetSurfaceDPI()" called Application::GetScaleFactor(), which always returns 0. So surfaceDPI is never updated and keeps returning 108 whether the screen is scaled.
I also changed the external display scaling to 1:1, and the triangle buttons are back, but menu position is still wrong.
I am not familiar with the smooth library and it is not documented. So would you please give some hints about what code segment sor variables should be checked and I can go on debugging.
Thank you for digging deeper into this!
Application::GetScaleFactor() will return non-zero only if you use the --scale:n.n command line argument to fre:ac to set a custom scale factor.
The behavior of SurfaceCocoa::GetSurfaceDPI() seems correct, as macOS should handle the scaling all by itself (so the application can always assume 96 DPI even if the actual DPI value is different).
It would be interesting where the actual crash happens, but if there is no crash reporter dialog showing up, it may be some kind of crash that is difficult to track down.
The bad window placement is probably due to some missing coordinate conversion (sth. like convertRectToScreen:) when placing the window in windowcocoa.mm.
What about the position and behavior of other drop down menus (e.g. the encoder drop down in the toolbar) or drop down lists (e.g. the Genre drop down). Are they also wrong?
Hi Robert,
I don't have much time these days cause I'm composing my doctor thesis. I can do limited test only.
Today I have an interesting founding:
With my external display (Dell P2715Q, 3840x2160) tuned to native resolution, the relative position of fre:ac window to desktop affect the program.
Put fre:ac to right-bottom corner of the external display, it works well! Put fre:ac to left-bottom corner of the external display, the triangle buttons show while mouse cursor-on, but I cannot trigger menu positioning bug anymore. I click the button then program crash. Put fre:ac to mid-bottom of the external display, all the triangles button show, the most right-side ones works well, and the left-side ones trigger crash. (strange) Put fre:ac to top half of external display, the triangle button won't show, but the menus show when I click to the area. (interesting!) Put fre:ac to middle of external display, the triangle buttons show correctly, but all the menus are shifted to right-down(not the corner)
It seems there're 2 bugs. One is with triangle button show/hide, the other is with menu positioning.
And I guess when the menu position is too far outside the display, it crashes?
I tried start up fre:ac with lldb, but also no crash information such as stack trace or something. Maybe I should turn on debugging options and symbols of smooth and fre:ac and test again? How can I do it properly?
Robert Kausch [email protected] 于2020年10月4日周日 上午7:44写道：
Thank you for digging deeper into this!
Application::GetScaleFactor() will return non-zero only if you use the --scale:n.n command line argument to fre:ac to set a custom scale factor.
The behavior of SurfaceCocoa::GetSurfaceDPI() seems correct, as macOS should handle the scaling all by itself (so the application can always assume 96 DPI even if the actual DPI value is different).
It would be interesting where the actual crash happens, but if there is no crash reporter dialog showing up, it may be some kind of crash that is difficult to track down.
The bad window placement is probably due to some missing coordinate conversion (sth. like convertRectToScreen: https://developer.apple.com/documentation/appkit/nswindow/1419286-convertrecttoscreen) when placing the window in windowcocoa.mm.
What about the position and behavior of other drop down menus (e.g. the encoder drop down in the toolbar) or drop down lists (e.g. the Genre drop down). Are they also wrong?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enzo1982/freac/issues/152#issuecomment-703178031, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEJOLX2DTRPXZISE4U6BKDSI6ZN7ANCNFSM4R6GJTKQ .
Thank you for your analysis! This will definitely give me a head start for my own experiments when I get the monitor cable.
I agree with your conclusion that there probably are two bugs and the crash happens when the menu is requested to open outside of the display area.
If you built everything using the build-freac script, smooth and fre:ac will have debug symbols enabled already. So it remains a bit mysterious why the crash happens without interrupting the debugger. Maybe the Cocoa framework is just calling exit() when a window is requested at invalid coordinates. It's possible that it's printing a message to stderr which you won't see when running the packaged app. Try running /usr/local/bin/freac from the command line.
Hopefully tomorrow evening I can try to reproduce the issue here.
Run from command line and only a "segmentation fault" showed up.
LLDB also display something like "access invalid address 0x00000000" but no other useful information.
Robert Kausch [email protected] 于2020年10月5日周一 上午6:17写道：
Thank you for your analysis! This will definitely give me a head start for my own experiments when I get the monitor cable.
I agree with your conclusion that there probably are two bugs and the crash happens when the menu is requested to open outside of the display area.
If you built everything using the build-freac script, smooth and fre:ac will have debug symbols enabled already. So it remains a bit mysterious why the crash happens without interrupting the debugger. Maybe the Cocoa framework is just calling exit() when a window is requested at invalid coordinates. It's possible that it's printing a message to stderr which you won't see when running the packaged app. Try running /usr/local/bin/freac from the command line.
Hopefully tomorrow evening I can try to reproduce the issue here.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enzo1982/freac/issues/152#issuecomment-703323883, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEJOLWDPDZQ5H6FCJF5KZDSJDX65ANCNFSM4R6GJTKQ .
Hope you've got your DP cable work, or I can do more test at my spot.
Furthermore I found a flaw in smooth library.
Cause I don't know how to trace into a dylib, I put some printf into smooth source code to trace it. I found that if I move mouse cursor inside a text input box, the GetScaleFactor() is called many times. I think is called by redraw triangle button. But if cursor is not moving across the border, it should not be called cause the button is no need to redraw.
Robert Kausch [email protected] 于2020年10月5日周一 上午6:17写道：
Thank you for your analysis! This will definitely give me a head start for my own experiments when I get the monitor cable.
I agree with your conclusion that there probably are two bugs and the crash happens when the menu is requested to open outside of the display area.
If you built everything using the build-freac script, smooth and fre:ac will have debug symbols enabled already. So it remains a bit mysterious why the crash happens without interrupting the debugger. Maybe the Cocoa framework is just calling exit() when a window is requested at invalid coordinates. It's possible that it's printing a message to stderr which you won't see when running the packaged app. Try running /usr/local/bin/freac from the command line.
Hopefully tomorrow evening I can try to reproduce the issue here.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enzo1982/freac/issues/152#issuecomment-703323883, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEJOLWDPDZQ5H6FCJF5KZDSJDX65ANCNFSM4R6GJTKQ .
Yes, I got the cable today and was able to reproduce the issue.
The debugger was not very helpful indeed. Like you described, it just prints "invalid address 0x0" with no stack trace. With printf messages, however, I was able to track the crash down to the GetScaleFactor() method.
The problem is that under some circumstances, the popup window is drawn outside of the screen area and then [window screen] returns nil, querying the backingScaleFactor selector fails and a call is made to address 0x0.
So the crash can easily be avoided by checking the result of [window screen] and returning 1.0 if it's nil.
The actual issue, however, is why the window is placed off-screen at all. It apparently has something to do with how screen coordinates are handled when multiple screens are active, but I still need to track down where it's going wrong.
Didn't have much time to look into this today. I'll see if I can find out more in the next few days.
So, I tracked this down to missing bits in screencocoa.mm as the main culprit. The file was last touched in 2013 and written as a stub implementation to be finished later, which obviously never happened.
All methods there simply return the metrics of the main screen, no matter how many screens are attached or which screen the pointer is on. I'll have a fix for this ready today or tomorrow. So far it looks promising.
Another aspect is the coordinate system conversion happening in windowcocoa.mm. In most instances, [[wnd screen] frame].size.height is used for this, which is wrong. [NSScreen mainScreen] needs to be used instead of [wnd screen] as the coordinate system needs to be flipped around the main screen's origin, not for each screen individually.
Third, the size calculations in micromenu.cpp and some other places that are done before opening a popup window do not account for screens with a non-null origin. Thus they really work for the main screen only.
I'm not yet sure if fixing these issues will be enough to also fix the menu buttons not appearing when working on an external display. It's possible that this is caused by the messed up coordinate system conversion, but there may be more to it.
I just pushed a series of commits to the smooth and fre:ac repositories to fix this issue. The most important one is enzo1982/smooth@e451289 which implements the missing bits in screencocoa.mm and fixes the coordinate conversions in windowcocoa.mm.
Scrap that [NSScreen mainScreen] from my previous comment. It should be [[NSScreen screens] objectAtIndex: 0]. The former actually is the screen containing the currently focused window while only the latter is the primary screen with the 0,0 origin.
Fortunately, this also fixed the drawing issues when on the second screen, so everything should be working fine now.
It would be great if you could try the update and verify that it's working. I put a binary up on freac.org for you. I plan to publish the 1.1.3 update on Sunday if everything goes well.
Thank you for reporting this issue and for your help with analyzing it! Greatly appreciated!
I'll test it tonight. It's a pity that my poor debug level and not enough time to help more.
Thanks for your great work.
Robert Kausch [email protected] 于2020年10月9日周五 上午7:41写道：
I just pushed a series of commits to the smooth and fre:ac repositories to fix this issue. The most important one is enzo1982/smooth@e451289 https://github.com/enzo1982/smooth/commit/e451289 which implements the missing bits in screencocoa.mm and fixes the coordinate conversions in windowcocoa.mm.
Scrap that [NSScreen mainScreen] from my previous comment. It should be [[NSScreen screens] objectAtIndex: 0]. The former actually is the screen containing the currently focused window while only the latter is the primary screen with the 0,0 origin.
Fortunately, this also fixed the drawing issues when on the second screen, so everything should be working fine now.
It would be great if you could try the update and verify that it's working. I put a binary up on freac.org https://freac.org/updates/freac-1.1.2-20201009-macosx.dmg for you. I plan to publish the 1.1.3 update on Sunday if everything goes well.
Thank you for reporting this issue and for your help with analyzing it! Greatly appreciated!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enzo1982/freac/issues/152#issuecomment-705884567, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEJOLWC3URVG22WYZCVG3DSJZE2DANCNFSM4R6GJTKQ .
Hi Robert,
The button drawing is totally correct during my testing.
The menu positioning is OK at most case, but it still shift away if I place fre:ac at bottom-left corner of my external display.
The external display is 4K resolution and zoomed to 3360x1890. It's placed to up-right of my internal display.
I attached the shifting screen shot, and the placement of my displays. Hope these can help.
Thanks for giving it a try! I cannot reproduce the remaining issue, unfortunately. I'll keep on trying, but I'm going to release the update tomorrow anyway.
If I got a spare, I'll dig into it again. You can close this issue for sure. It never crash anymore.
It's a happy time working with you.
It would be great if you could find out more about the remaining issue. You could set a breakpoint in MicroMenu::OpenPopupMenu() in micromenu.cpp and check the popup coordinate computation. Then maybe another one in WindowCocoa::Open() in windowcocoa.mm to see what actually gets passed to the Cocoa window.
I'd like to leave this issue open until we know more about this.
It's great working with you too! Thanks to your help, this fix made it into today's release and certainly lots of fre:ac users will benefit from it.