Random application crash on Apple Silicon M1 (Qt 6.2.3)
-
I was finally able to build all libs for x64_64 and thus I can build my app for x86_64. It seems not to crash but there are few other observations that might be related:
- it seems that crashes are more frequent when I start my Mac after some time and the they are less and less happening (I know that this sounds very strange but it is my observation from today and also yesterday). So far it seems to be fully random and I still do not know what to do to make it crash.
- When I start my laptop today and started the app it was crashing almost immediately. I am running it with thread sanitizer and the crash happened even before any message about data race appeared. At the moment I am running the app for >10minutes without crash.
- x86_64 does not seem to crash, no crash observed so far but it could be related to previous point
- my feeling (only a feeling) is that it crashes more frequently when the application get focus or when I move mouse over it etc. However intensive interaction with UI (fast clicking on GUI elements) does not seem to cause crash.
EDIT: I have fixed all reported data race cases using message queue 2 days ago and today when I started my Mac it was again crashing almost immediately. After some time it is crashing less frequently. This is absolutely crazy, I do not understand it at all :-( I will try x86_64 build tomorrow but for the moment I do not know what else to do.
-
I was finally able to build all libs for x64_64 and thus I can build my app for x86_64. It seems not to crash but there are few other observations that might be related:
- it seems that crashes are more frequent when I start my Mac after some time and the they are less and less happening (I know that this sounds very strange but it is my observation from today and also yesterday). So far it seems to be fully random and I still do not know what to do to make it crash.
- When I start my laptop today and started the app it was crashing almost immediately. I am running it with thread sanitizer and the crash happened even before any message about data race appeared. At the moment I am running the app for >10minutes without crash.
- x86_64 does not seem to crash, no crash observed so far but it could be related to previous point
- my feeling (only a feeling) is that it crashes more frequently when the application get focus or when I move mouse over it etc. However intensive interaction with UI (fast clicking on GUI elements) does not seem to cause crash.
EDIT: I have fixed all reported data race cases using message queue 2 days ago and today when I started my Mac it was again crashing almost immediately. After some time it is crashing less frequently. This is absolutely crazy, I do not understand it at all :-( I will try x86_64 build tomorrow but for the moment I do not know what else to do.
@KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
I was finally able to build all libs for x64_64 and thus I can build my app for x86_64. It seems not to crash but there are few other observations that might be related:
- it seems that crashes are more frequent when I start my Mac after some time and the they are less and less happening (I know that this sounds very strange but it is my observation from today and also yesterday). So far it seems to be fully random and I still do not know what to do to make it crash.
- When I start my laptop today and started the app it was crashing almost immediately. I am running it with thread sanitizer and the crash happened even before any message about data race appeared. At the moment I am running the app for >10minutes without crash.
- x86_64 does not seem to crash, no crash observed so far but it could be related to previous point
- my feeling (only a feeling) is that it crashes more frequently when the application get focus or when I move mouse over it etc. However intensive interaction with UI (fast clicking on GUI elements) does not seem to cause crash.
EDIT: I have fixed all reported data race cases using message queue 2 days ago and today when I started my Mac it was again crashing almost immediately. After some time it is crashing less frequently. This is absolutely crazy, I do not understand it at all :-( I will try x86_64 build tomorrow but for the moment I do not know what else to do.
I am having the exact same random crash symptoms with the same stack trace you reported earlier on my M1 MacBook Pro on my completely unrelated application: https://github.com/sultanqasim/cinemavi/tree/master/CMGui
My stack trace:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x0 ??? 1 ImageIO 0x1b06cac68 IIOReadPlugin::callInitialize() + 120 2 ImageIO 0x1b06ca98c IIO_Reader::initImageAtOffset(CGImagePlugin*, unsigned long, unsigned long, unsigned long) + 108 3 ImageIO 0x1b06c8228 IIOImageSource::makeImagePlus(unsigned long, IIODictionary*) + 748 4 ImageIO 0x1b06d4834 IIOImageSource::createImageAtIndex(unsigned long, IIODictionary*) + 80 5 ImageIO 0x1b06d4704 CGImageSourceCreateImageAtIndex + 256 6 HIServices 0x1ad30beb4 setCursorFromBundle + 2232 7 HIServices 0x1ad30aebc CoreCursorSetAndReturnSeed + 204 8 AppKit 0x1aa44a1ec -[NSCursor _reallySet] + 684 9 AppKit 0x1aa453354 +[NSCursor _setOverrideCursor:type:] + 300 10 AppKit 0x1aa452b38 -[NSWindow(NSWindowResizing) _edgeResizingCursorUpdate:atLocation:] + 288 11 AppKit 0x1aa41a304 -[NSApplication(NSEvent) sendEvent:] + 664 12 libqcocoa.dylib 0x10376987c 0x103760000 + 39036 13 AppKit 0x1aa6d48e8 -[NSApplication _handleEvent:] + 76 14 AppKit 0x1aa29c6b8 -[NSApplication run] + 636 15 libqcocoa.dylib 0x103774fb8 0x103760000 + 85944 16 QtCore 0x104a18b3c QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 500 17 QtCore 0x104a0fe88 QCoreApplication::exec() + 128 18 Cinemavi 0x10291d528 main + 564 (main.cpp:22) 19 dyld 0x102cf9088 start + 516 -
I wasn't getting this crash on Mac OS 12.2.1 and earlier, but I just upgraded to Mac OS 12.3 today, and I've been getting this crash ever since then. My application was rock solid stable before today's upgrade, but is unusable due to the frequency of this particular crash now.
-
Also, for reference, I have no issues with AddressSanitizer or ThreadSanitizer, and UBSan gives the same warnings as the OP had, such as:
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior moc_cmpicturelabel.cpp:116:28 in moc_cmrenderworker.cpp:112:28: runtime error: member access within address 0x000109723180 which does not point to an object of type 'QObjectData' 0x000109723180: note: object is of type 'QObjectPrivate' 00 00 00 00 90 0d 87 04 01 00 00 00 20 59 81 0a 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'QObjectPrivate' -
Ok, seems like a potential bug with the latest macOS on M1 arch,
have you guys tried and reproduced it with a minimal example?
-
I wasn't getting this crash on Mac OS 12.2.1 and earlier, but I just upgraded to Mac OS 12.3 today, and I've been getting this crash ever since then. My application was rock solid stable before today's upgrade, but is unusable due to the frequency of this particular crash now.
@sultan said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
I wasn't getting this crash on Mac OS 12.2.1 and earlier, but I just upgraded to Mac OS 12.3 today, and I've been getting this crash ever since then. My application was rock solid stable before today's upgrade, but is unusable due to the frequency of this particular crash now.
This is very interesting observation. Unfortunately I have upgraded my new Mac immediately after getting it so I did not try with macOS < 12.3.
@J-Hilk said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
have you guys tried and reproduced it with a minimal example?
I am afraid it would be difficult. My feeling is that it happens in more complex multi-thread applications. I will continue my investigations, I already have some more ideas what to try and in case I find something I will for sure report is here.
-
Interestingly, I'm unable to reproduce my crash today. It was consistently crashing within a couple minutes or sometimes less yesterday for me, but it hasn't crashed even once for me today. This sounds like it'll be a tricky bug to diagnose.
EDIT: I just rebooted my computer, and now it crashes all the time again. For reference, I hadn't rebooted in over a month before yesterday's update to MacOS 12.3. Maybe these crashes are unrelated to MacOS 12.3, and just related to how long it has been since the computer was last rebooted. Bizarre nevertheless. I'll see if I can make a minimal application crash with this when I have time.
-
Interestingly, I'm unable to reproduce my crash today. It was consistently crashing within a couple minutes or sometimes less yesterday for me, but it hasn't crashed even once for me today. This sounds like it'll be a tricky bug to diagnose.
EDIT: I just rebooted my computer, and now it crashes all the time again. For reference, I hadn't rebooted in over a month before yesterday's update to MacOS 12.3. Maybe these crashes are unrelated to MacOS 12.3, and just related to how long it has been since the computer was last rebooted. Bizarre nevertheless. I'll see if I can make a minimal application crash with this when I have time.
-
I have some observations to share. My app uses several libs installed by homebrew, specifically:
- libmpg123
- faad2
- portaudio
- librtlsdr that uses libusb to access RTL-SDR USB stick
If I build all these by myself and link my application with them it seems that it is no longer crashing. My suspicion would be libusb. I am trying to run the app with only librtlsdr + libusb from my own build and so far it seems to work or it is significantly less frequent. I need to test it more but it looks promising.
@sultan : Does your application use any of these libs, especially libusb?
EDIT: it just crashed :-( I will try with all libs from my local build that was working fine yesterday.
EDIT2: application does not crash when linked will above listed libs built locally on my Mac and not taken from Homebrew. I have tried to isolate the problem to single library with no success so far. I will continue my investigations and try to find more information. -
I have some observations to share. My app uses several libs installed by homebrew, specifically:
- libmpg123
- faad2
- portaudio
- librtlsdr that uses libusb to access RTL-SDR USB stick
If I build all these by myself and link my application with them it seems that it is no longer crashing. My suspicion would be libusb. I am trying to run the app with only librtlsdr + libusb from my own build and so far it seems to work or it is significantly less frequent. I need to test it more but it looks promising.
@sultan : Does your application use any of these libs, especially libusb?
EDIT: it just crashed :-( I will try with all libs from my local build that was working fine yesterday.
EDIT2: application does not crash when linked will above listed libs built locally on my Mac and not taken from Homebrew. I have tried to isolate the problem to single library with no success so far. I will continue my investigations and try to find more information. -
@KejPi My application uses libaravis from homebrew, which depends on libusb (also from homebrew).
-
@sultan Could you please try to build both libs locally and link your application with them? Since I did that for all my libs, I do not have problems with crashes but it seems that all have to be built locally - I do not understand it at all :-(
-
I'm seeing this exact crash with all libraries locally built, none of the libraries listed here and built on Gtk (yes, I'm in the wrong forum :). So I think this is likely a MacOS bug, but I don't know for sure.
Here's my stack trace:
__read_nocancel (@__read_nocancel:5) __sread (@__sread:9) _sread (@_sread:11) __srefill1 (@__srefill1:12) fgets (@fgets:31) gimp_stack_trace_query (/Users/user/gtk/source/gimp/libgimpbase/gimputils.c:1511) gimp_plugin_sigfatal_handler (/Users/user/gtk/source/gimp/libgimp/gimp.c:1004) _sigtramp (@_sigtramp:17) PNGReadPlugin::InitializePluginData(IIOImageReadSession*, IIODictionary*, IIODictionary*, CGImageMetadata*, CGColorSpace**, ReadPluginData&, PNGPluginData&, __CFDictionary*) (@PNGReadPlugin::InitializePluginData(IIOImageReadSession*, IIODictionary*, IIODictionary*, CGImageMetadata*, CGColorSpace**, ReadPluginData&, PNGPluginData&, __CFDictionary*):204) IIOReadPlugin::callInitialize() (@IIOReadPlugin::callInitialize():33) IIO_Reader::initImageAtOffset(CGImagePlugin*, unsigned long, unsigned long, unsigned long) (@IIO_Reader::initImageAtOffset(CGImagePlugin*, unsigned long, unsigned long, unsigned long):30) IIOImageSource::makeImagePlus(unsigned long, IIODictionary*) (@IIOImageSource::makeImagePlus(unsigned long, IIODictionary*):190) IIOImageSource::createImageAtIndex(unsigned long, IIODictionary*) (@IIOImageSource::createImageAtIndex(unsigned long, IIODictionary*):23) CGImageSourceCreateImageAtIndex (@CGImageSourceCreateImageAtIndex:67) setCursorFromBundle (@setCursorFromBundle:561) CoreCursorSetAndReturnSeed (@CoreCursorSetAndReturnSeed:54) -[NSCursor _reallySet] (@-[NSCursor _reallySet]:174) -[NSCursor set] (@-[NSCursor set]:43) gdk_window_quartz_set_device_cursor (/Users/user/gtk/source/gtk+-3.24.31/gdk/quartz/gdkwindow-quartz.c:1717) update_cursor (/Users/user/gtk/source/gtk+-3.24.31/gdk/gdkwindow.c:7647) _gdk_display_set_window_under_pointer (/Users/user/gtk/source/gtk+-3.24.31/gdk/gdkwindow.c:8589) proxy_pointer_event (/Users/user/gtk/source/gtk+-3.24.31/gdk/gdkwindow.c:9313) _gdk_windowing_got_event (/Users/user/gtk/source/gtk+-3.24.31/gdk/gdkwindow.c:10071) _gdk_quartz_display_queue_events (/Users/user/gtk/source/gtk+-3.24.31/gdk/quartz/gdkevents-quartz.c:1802) gdk_event_dispatch (/Users/user/gtk/source/gtk+-3.24.31/gdk/quartz/gdkeventloop-quartz.c:709) g_main_dispatch (/Users/user/gtk/source/glib-2.70.0/glib/gmain.c:3381) g_main_context_dispatch (/Users/user/gtk/source/glib-2.70.0/glib/gmain.c:4099) g_main_context_iterate (/Users/user/gtk/source/glib-2.70.0/glib/gmain.c:4175) g_main_loop_run (/Users/user/gtk/source/glib-2.70.0/glib/gmain.c:4373) gimp_dialog_run (/Users/user/gtk/source/gimp/libgimpwidgets/gimpdialog.c:657) ffi_call_SYSV (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/sysv.S:127) ffi_call_int (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/ffi.c:762) ffi_call (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/ffi.c:771) pygi_invoke_c_callable (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:684) _function_cache_invoke_real (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-cache.c:783) pygi_function_cache_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-cache.c:862) pygi_callable_info_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:727) _wrap_g_callable_info_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:764) _callable_info_call (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-info.c:548) _function_info_call (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-info.c:609) _PyObject_MakeTpCall (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:191) _PyObject_VectorcallTstate (/Users/user/gtk/source/Python-3.9.12/Include/cpython/abstract.h:116) PyObject_Vectorcall (/Users/user/gtk/source/Python-3.9.12/Include/cpython/abstract.h:127) call_function (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:5077) _PyEval_EvalFrameDefault (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:3489) _PyEval_EvalFrame (/Users/user/gtk/source/Python-3.9.12/Include/internal/pycore_ceval.h:40) function_code_fastcall (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:330) _PyFunction_Vectorcall (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:367) _PyObject_VectorcallTstate (/Users/user/gtk/source/Python-3.9.12/Include/cpython/abstract.h:118) method_vectorcall (/Users/user/gtk/source/Python-3.9.12/Objects/classobject.c:83) PyVectorcall_Call (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:231) _PyObject_Call (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:266) PyObject_CallObject (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:457) _pygi_closure_handle (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-closure.c:582) ffi_closure_SYSV_inner (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/ffi.c:1045) ffi_closure_SYSV (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/sysv.S:297) gimp_image_procedure_run (/Users/user/gtk/source/gimp/libgimp/gimpimageprocedure.c:170) gimp_procedure_run (/Users/user/gtk/source/gimp/libgimp/gimpprocedure.c:1897) gimp_plug_in_proc_run_internal (/Users/user/gtk/source/gimp/libgimp/gimpplugin.c:1229) gimp_plug_in_proc_run (/Users/user/gtk/source/gimp/libgimp/gimpplugin.c:1176) gimp_plug_in_loop (/Users/user/gtk/source/gimp/libgimp/gimpplugin.c:1084) _gimp_plug_in_run (/Users/user/gtk/source/gimp/libgimp/gimpplugin.c:833) gimp_main (/Users/user/gtk/source/gimp/libgimp/gimp.c:539) ffi_call_SYSV (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/sysv.S:127) ffi_call_int (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/ffi.c:762) ffi_call (/Users/user/gtk/source/libffi-3.4.2/src/aarch64/ffi.c:771) pygi_invoke_c_callable (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:684) _function_cache_invoke_real (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-cache.c:783) pygi_function_cache_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-cache.c:862) pygi_callable_info_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:727) _wrap_g_callable_info_invoke (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-invoke.c:764) _callable_info_call (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-info.c:559) _function_info_call (/Users/user/gtk/source/pygobject-3.42.0/gi/pygi-info.c:609) _PyObject_MakeTpCall (/Users/user/gtk/source/Python-3.9.12/Objects/call.c:191) _PyObject_VectorcallTstate (/Users/user/gtk/source/Python-3.9.12/Include/cpython/abstract.h:116) PyObject_Vectorcall (/Users/user/gtk/source/Python-3.9.12/Include/cpython/abstract.h:127) call_function (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:5077) _PyEval_EvalFrameDefault (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:3489) _PyEval_EvalFrame (/Users/user/gtk/source/Python-3.9.12/Include/internal/pycore_ceval.h:40) _PyEval_EvalCode (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:4329) _PyEval_EvalCodeWithName (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:4361) PyEval_EvalCodeEx (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:4377) PyEval_EvalCode (/Users/user/gtk/source/Python-3.9.12/Python/ceval.c:828) run_eval_code_obj (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:1221) run_mod (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:1242) pyrun_file (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:1140) pyrun_simple_file (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:450) PyRun_SimpleFileExFlags (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:483) PyRun_AnyFileExFlags (/Users/user/gtk/source/Python-3.9.12/Python/pythonrun.c:92) pymain_run_file (/Users/user/gtk/source/Python-3.9.12/Modules/main.c:373) pymain_run_python (/Users/user/gtk/source/Python-3.9.12/Modules/main.c:598) Py_RunMain (/Users/user/gtk/source/Python-3.9.12/Modules/main.c:677) pymain_main (/Users/user/gtk/source/Python-3.9.12/Modules/main.c:707) Py_BytesMain (/Users/user/gtk/source/Python-3.9.12/Modules/main.c:731) main (/Users/user/gtk/source/Python-3.9.12/Programs/python.c:15) start (@start:132) -
Do you have the same issue if you use a Qt version coming from the online installer rather that brew ?
-
I'm still having the same issue, same crash stack trace, on Mac OS 12.6.3 with Qt 6.4.2. I haven't yet gotten to trace my way to the root cause, though it looks like this will be a PITA to debug.
@sultan have you tried to completely remove homebrew from your system and then reinstall only the needed library for your app? I have seen a CERN ROOT framework crash that was related to a "wrong" library being somewhere in LD_LIBRARY_PATH which was causing the crashes similar to these described here.
-
Do you have the same issue if you use a Qt version coming from the online installer rather that brew ?
-
@sultan have you tried to completely remove homebrew from your system and then reinstall only the needed library for your app? I have seen a CERN ROOT framework crash that was related to a "wrong" library being somewhere in LD_LIBRARY_PATH which was causing the crashes similar to these described here.
@DerReisende I think you're on the right track here. When launching the application from Qt Creator, it consistently crashes (after some random delay) when the computer has been rebooted recently. When launching the application from command line (going into the .app bundle's Contents/MacOS directory and invoking the executable from there), it never crashes. So there is definitely some library mismatch happening when launching through Qt creator that is avoided when launching from the command line.
For reference, when launching from the command line (where it doesn't crash),
PATH=opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binandLD_LIBRARY_PATHis not set. When launching from Qt Creator (where it crashes),PATH=/Users/sultan/Qt/6.4.2/macos/bin:/usr/bin:/bin:/usr/sbin:/sbin,QTDIR=/Users/sultan/Qt/6.4.2/macos, andLD_LIBRARY_PATHis again not set. -
@DerReisende I think you're on the right track here. When launching the application from Qt Creator, it consistently crashes (after some random delay) when the computer has been rebooted recently. When launching the application from command line (going into the .app bundle's Contents/MacOS directory and invoking the executable from there), it never crashes. So there is definitely some library mismatch happening when launching through Qt creator that is avoided when launching from the command line.
For reference, when launching from the command line (where it doesn't crash),
PATH=opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binandLD_LIBRARY_PATHis not set. When launching from Qt Creator (where it crashes),PATH=/Users/sultan/Qt/6.4.2/macos/bin:/usr/bin:/bin:/usr/sbin:/sbin,QTDIR=/Users/sultan/Qt/6.4.2/macos, andLD_LIBRARY_PATHis again not set.@sultan said in Random application crash on Apple Silicon M1 (Qt 6.2.3):
@DerReisende I think you're on the right track here. When launching the application from Qt Creator, it consistently crashes (after some random delay) when the computer has been rebooted recently. When launching the application from command line (going into the .app bundle's Contents/MacOS directory and invoking the executable from there), it never crashes. So there is definitely some library mismatch happening when launching through Qt creator that is avoided when launching from the command line.
For reference, when launching from the command line (where it doesn't crash),
PATH=opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binandLD_LIBRARY_PATHis not set. When launching from Qt Creator (where it crashes),PATH=/Users/sultan/Qt/6.4.2/macos/bin:/usr/bin:/bin:/usr/sbin:/sbin,QTDIR=/Users/sultan/Qt/6.4.2/macos, andLD_LIBRARY_PATHis again not set.It seems just launching the application from Finder (by clicking on the .app bundle) also works properly with no crash - at least I have not been able to reproduce any crashes that way, whereas I've been able to reproduce this crash almost a dozen times today when launching the app via Qt Creator (soon after a reboot).
-
Same crash here, happened consistently as soon as I did a filesystem save operation in my soft: i could fix it by unchecking "Add build library search path to DYLD_LIBRARY_PATH and DYLD_FRAMEORK_PATH" in Qt Creator's Project > Run tab.
@sultan note that LD_LIBRARY_PATH is for ELF platforms, MacOS uses DYLD_LIBRARY_PATH
Trying on a terminal, I can see that just adding /opt/homebrew/lib to DYLD_LIBRARY_PATH is sufficient to trigger the crash.
