Random application crash on Apple Silicon M1 (Qt 6.2.3)
-
I have installed it using Homebrew - https://brew.sh/
I have compiled the application on Win and run it for about 8 hours without any problem so it seems that the problem is related to M1 version, it was also no problem on Intel Mac I had before.
This is what I get on crash, I am not sure if it helps:
1 None No value 2 PNGReadPlugin::InitializePluginData(IIOImageReadSession *, IIODictionary *, IIODictionary *, CGImageMetadata *, CGColorSpace * *, ReadPluginData&, PNGPluginData&, __CFDictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86c6f8c 3 IIOReadPlugin::callInitialize() (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86bec68 4 IIO_Reader::initImageAtOffset(CGImagePlugin *, unsigned long, unsigned long, unsigned long) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86be98c 5 IIOImageSource::makeImagePlus(unsigned long, IIODictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86bc228 6 IIOImageSource::createImageAtIndex(unsigned long, IIODictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86c8834 7 CGImageSourceCreateImageAtIndex (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1a86c8704 8 setCursorFromBundle (arm64e) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x1a52ffeb4 9 CoreCursorSetAndReturnSeed (arm64e) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x1a52feebc 10 -[NSCursor _reallySet] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a243e1ec 11 +[NSCursor _setOverrideCursor:type:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a2447354 12 -[NSWindow(NSWindowResizing) _edgeResizingCursorUpdate:atLocation:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a2446b38 13 -[NSApplication(NSEvent) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a240e304 14 -[QNSApplication sendEvent:] (arm64) /opt/homebrew/Cellar/qt/6.2.3_1/share/qt/plugins/platforms/libqcocoa.dylib 0x105f087d4 15 -[NSApplication _handleEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a26c88e8 16 -[NSApplication run] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x1a22906b8 17 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (arm64) /opt/homebrew/Cellar/qt/6.2.3_1/share/qt/plugins/platforms/libqcocoa.dylib 0x105f13e4c 18 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (arm64) /opt/homebrew/opt/qt/lib/QtCore.framework/Versions/A/QtCore 0x1054b4c94 19 QCoreApplication::exec() (arm64) /opt/homebrew/opt/qt/lib/QtCore.framework/Versions/A/QtCore 0x1054abfe0 20 main main.cpp 10 0x10001d098 21 start (arm64e) /usr/lib/dyld 0x1035c5088@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
I have installed it using Homebrew
I would suggest to ask them, maybe file a bug if possible.
-
Hello guys, I have a weird problem with my Qt app on M1. I have upgraded from Intel Mac to Apple Silicon MAC recently and since then my application started to crash from time to time. The crash seems to be fully random. If I run the application with debugger attached then it stops on a.exec():
int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); return a.exec(); // <=== here the debugger stops }I have installed Qt 6.2.3 using homebrew and to be honest I have no idea how to debug this, problem seems to be somewhere in the libs.
Does anybody else see this problem?
Would it make sense to install Qt using online installer?Thanks for any hint!
@KejPi I am using the online installer version on M1 Mac and havent experienced any crashes with it - aside my errors ;)
-
I have uninstalled Qt from home-brew, installed 6.2.3 using online installer and unfortunately still I can catch the crash - with much lower frequency though.
This is stack trace:
1 None No value 2 PNGReadPlugin::InitializePluginData(IIOImageReadSession *, IIODictionary *, IIODictionary *, CGImageMetadata *, CGColorSpace * *, ReadPluginData&, PNGPluginData&, __CFDictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955d6f8c 3 IIOReadPlugin::callInitialize() (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955cec68 4 IIO_Reader::initImageAtOffset(CGImagePlugin *, unsigned long, unsigned long, unsigned long) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955ce98c 5 IIOImageSource::makeImagePlus(unsigned long, IIODictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955cc228 6 IIOImageSource::createImageAtIndex(unsigned long, IIODictionary *) (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955d8834 7 CGImageSourceCreateImageAtIndex (arm64e) /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x1955d8704 8 setCursorFromBundle (arm64e) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x19220feb4 9 CoreCursorSetAndReturnSeed (arm64e) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x19220eebc 10 -[NSCursor _reallySet] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f34e1ec 11 +[NSCursor _setOverrideCursor:type:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f357354 12 -[NSWindow(NSWindowResizing) _edgeResizingCursorUpdate:atLocation:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f356b38 13 -[NSApplication(NSEvent) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f31e304 14 -[QNSApplication sendEvent:] qcocoaapplication.mm 176 0x10502d87c 15 -[NSApplication _handleEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f5d88e8 16 -[NSApplication run] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x18f1a06b8 17 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) qcocoaeventdispatcher.mm 430 0x105038fb8 18 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) qeventloop.cpp 139 0x105508b3c 19 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) qeventloop.cpp 230 0x105508b18 20 QCoreApplication::exec() qcoreapplication.cpp 1382 0x1054ffe88 21 main main.cpp 10 0x10001c728 22 start (arm64e) /usr/lib/dyld 0x1035c5088 -
Hi,
Can you provide a minimal compilable example that reproduces this crash ?
-
Well, this will be probably a big problem. My application is not simple, it does DAB receiver and I honestly do not know what it the real cause of the crash. It just happens from time to time, probably it could be related to some action that is caused by the the received stream but I am pretty sure that the code is functional without any issue when compiled for Win or for Mac Intel. I will try to isolate it root cause and and provide the example code if I find it.
EDIT: last time it took more that 15 minutes to catch the crash.
-
Are both the Qt builds you used x86_64 based or was the one from brew ARM based ?
-
If your dependencies can be satisfied by brew, you can still install them for x86_64. It requires two brew install though.
-
-
I was just thinking about testing your application with Rosetta2 to see if it behaved in the same fashion.
-
Yes, they can be satisfied by brew but I am not sure I want to do it because I do not have Intel Mac anymore so I cannot test it on Intel machine. I am thinking about installing virtual ARM linux a try there to see if it is ARM related or MacOS related.
@KejPi Are you using multi-threading in your app? At WWDC 2020 „Port your mac app to Apple Silicon“ there was a slide reminding developers that
- Intel CPUs and Apple Silicon have a different memory ordering model
- A data race on Intel might have appeared to be benign, but can be causing crashes on Apple Silicon
- Rosetta provides Intel CPU memory ordering
If your app works correct using Rosetta than I would guess you have one of the above mentioned problems.
You might as well have a problem with memory alignment, maybe this thread can give additional insight.
-
That is an interesting point. Actually I use several threads - input rtl-sdr driver initiates thread, backed DAB SDR library runs in normal Posix thread and that there are some GUI classes running in QThreads. In total it is about 14 threads. The threads that I create explicitly are started when the application starts, I am not sure about other threads that I do not control directly, but the application crashes after some time of running. Nevertheless, it seems your hint with x86_64 build seems to be more and more reasonable so I will try to build the libs and the application for x86_64 and see what is going to happen.
-
That is an interesting point. Actually I use several threads - input rtl-sdr driver initiates thread, backed DAB SDR library runs in normal Posix thread and that there are some GUI classes running in QThreads. In total it is about 14 threads. The threads that I create explicitly are started when the application starts, I am not sure about other threads that I do not control directly, but the application crashes after some time of running. Nevertheless, it seems your hint with x86_64 build seems to be more and more reasonable so I will try to build the libs and the application for x86_64 and see what is going to happen.
-
@DerReisende The discussion thread you have posted touches atomic access. My code actually relies on this functionality to share few simple control variables between threads to avoid using mutexes that are much heavier. Could this be an issue?
-
That is an interesting point. Actually I use several threads - input rtl-sdr driver initiates thread, backed DAB SDR library runs in normal Posix thread and that there are some GUI classes running in QThreads. In total it is about 14 threads. The threads that I create explicitly are started when the application starts, I am not sure about other threads that I do not control directly, but the application crashes after some time of running. Nevertheless, it seems your hint with x86_64 build seems to be more and more reasonable so I will try to build the libs and the application for x86_64 and see what is going to happen.
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
there are some GUI classes running in QThreads
mhm, is that something you have done?
Because GUI elements/classes are not allowed to run in a different thread from the one where QCoreApplication lives in!
-
@DerReisende The discussion thread you have posted touches atomic access. My code actually relies on this functionality to share few simple control variables between threads to avoid using mutexes that are much heavier. Could this be an issue?
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
@DerReisende The discussion thread you have posted touches atomic access. My code actually relies on this functionality to share few simple control variables between threads to avoid using mutexes that are much heavier. Could this be an issue?
It also talks about memory alignment of structs etc. where you should memcpy received data instead of e.g. just casting to a struct which may cause problems. But I am not really familiar with MT-programming, I just read those things while watching WWDC 2020 and searching for additional info. But IMHO data exchange with a std::atomic or equivalent should be fine. I suggested compilation with USBSAN only because maybe the compiler will warn you about unintentional undefined behaviour that may exist in your code - and might be the cause of your problems. And clang provides these checks OOTB therefore it might be worth a try.
I have so far not used Qt with MT therefore I would check @J-Hilk suggestions as well.
-
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
@DerReisende The discussion thread you have posted touches atomic access. My code actually relies on this functionality to share few simple control variables between threads to avoid using mutexes that are much heavier. Could this be an issue?
It also talks about memory alignment of structs etc. where you should memcpy received data instead of e.g. just casting to a struct which may cause problems. But I am not really familiar with MT-programming, I just read those things while watching WWDC 2020 and searching for additional info. But IMHO data exchange with a std::atomic or equivalent should be fine. I suggested compilation with USBSAN only because maybe the compiler will warn you about unintentional undefined behaviour that may exist in your code - and might be the cause of your problems. And clang provides these checks OOTB therefore it might be worth a try.
I have so far not used Qt with MT therefore I would check @J-Hilk suggestions as well.
@DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
where you should memcpy received data instead of e.g. just casting to a struct which may cause problems.
woa, we're talking c++ here right? casting memory to a stuct is undefined behaviour, among other things because it circumvents the constructor! You get away with it in C but not in C++, thats way dynamic_cast exists
-
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
there are some GUI classes running in QThreads
mhm, is that something you have done?
Because GUI elements/classes are not allowed to run in a different thread from the one where QCoreApplication lives in!
@J-Hilk said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
there are some GUI classes running in QThreads
mhm, is that something you have done?
Because GUI elements/classes are not allowed to run in a different thread from the one where QCoreApplication lives in!
I have not written it correctly, I did not want to go into details. My application consists of 2 parts - backend doing DAB demodulation and decoding, this is written in C and then the HMI part (frontend) that is written in C++ (Qt) and this controlling the backend, the input sources, doing audio and data decoding and playback, etc. And in the HMI part I have developed several classes and some of them run is separate thread but not those that have GUI elements, only some decodes, input devices, etc.
-
@DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
where you should memcpy received data instead of e.g. just casting to a struct which may cause problems.
woa, we're talking c++ here right? casting memory to a stuct is undefined behaviour, among other things because it circumvents the constructor! You get away with it in C but not in C++, thats way dynamic_cast exists
@J-Hilk said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
woa, we're talking c++ here right? casting memory to a stuct is undefined behaviour, among other things because it circumvents the constructor! You get away with it in C but not in C++, thats way dynamic_cast exists
I do not do this :-) Trying to do it C++ way where it is possible but I have to admit I am trying to optimize all real-time code as much as possible - like using std::atomic for instead of mutex, etc.
-
@DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
where you should memcpy received data instead of e.g. just casting to a struct which may cause problems.
woa, we're talking c++ here right? casting memory to a stuct is undefined behaviour, among other things because it circumvents the constructor! You get away with it in C but not in C++, thats way dynamic_cast exists
@J-Hilk said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
@DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
where you should memcpy received data instead of e.g. just casting to a struct which may cause problems.
woa, we're talking c++ here right? casting memory to a stuct is undefined behaviour, among other things because it circumvents the constructor! You get away with it in C but not in C++, thats way dynamic_cast exists
I have plenty of old code from former c programmers who used reinterpret_cast et al to convince the compiler to do what they wanted in really creative ways (created before y2k).
But anyways it was just (a maybe bad) example that the linked thread did not only talk about atomic ops.
If the OP doesnt do it - good. But still a compile run with the undefined behaviour sanitizer may find some problems that may fix the intermittent crashes of the app.
