Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Random application crash on Apple Silicon M1 (Qt 6.2.3)
Forum Updated to NodeBB v4.3 + New Features

Random application crash on Apple Silicon M1 (Qt 6.2.3)

Scheduled Pinned Locked Moved Unsolved General and Desktop
66 Posts 10 Posters 16.2k Views 6 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K KejPi

    @DerReisende Yes, it is exactly one producer-on consumer queue. Actually my idea was to "emulate" it by Qt::QueuedConnection. But in theory I can implement simple queue by myself since it is quite simple case. Nonetheless the problem mentioned by @J-Hilk that data live in T1 that creates them and used by T2 that uses and deletes them remains. But queue is a good idea how to solve it :-)

    D Offline
    D Offline
    DerReisende
    wrote on last edited by
    #36

    @KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):

    @DerReisende Yes, it is exactly one producer-on consumer queue. Actually my idea was to "emulate" it by Qt::QueuedConnection. But in theory I can implement simple queue by myself since it is quite simple case.

    Why reinvent the wheel when there are proven/well-tested solutions available? :D

    Nonetheless the problem mentioned by @J-Hilk that data live in T1 that creates them and used by T2 that uses and deletes them remains. But queue is a good idea how to solve it :-)

    What about using move semantics (std::move)? You should be able to move your RadioControlEvent in there and later move it out of the queue. But it would then require a move constructor.

    K 1 Reply Last reply
    0
    • K KejPi

      @DerReisende Yes, it is exactly one producer-on consumer queue. Actually my idea was to "emulate" it by Qt::QueuedConnection. But in theory I can implement simple queue by myself since it is quite simple case. Nonetheless the problem mentioned by @J-Hilk that data live in T1 that creates them and used by T2 that uses and deletes them remains. But queue is a good idea how to solve it :-)

      artwawA Offline
      artwawA Offline
      artwaw
      wrote on last edited by
      #37

      @KejPi Qt has QQueue, which is reentrant and thread-safe to some extent, https://doc.qt.io/qt-6/qqueue.html - but I am not sure if this will suit your needs. I used it, upon occasion, for the file processing backend to communicate/report to the UI frontend however my constraints were not as tight as yours I am afraid.

      For more information please re-read.

      Kind Regards,
      Artur

      1 Reply Last reply
      0
      • D DerReisende

        @KejPi said in Random application crash on Apple Silicon M1 (Qt 6.2.3):

        @DerReisende Yes, it is exactly one producer-on consumer queue. Actually my idea was to "emulate" it by Qt::QueuedConnection. But in theory I can implement simple queue by myself since it is quite simple case.

        Why reinvent the wheel when there are proven/well-tested solutions available? :D

        Nonetheless the problem mentioned by @J-Hilk that data live in T1 that creates them and used by T2 that uses and deletes them remains. But queue is a good idea how to solve it :-)

        What about using move semantics (std::move)? You should be able to move your RadioControlEvent in there and later move it out of the queue. But it would then require a move constructor.

        K Offline
        K Offline
        KejPi
        wrote on last edited by
        #38

        @DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):

        What about using move semantics (std::move)? You should be able to move your RadioControlEvent in there and later move it out of the queue. But it would then require a move constructor.

        Yes, but this implies Qt6, so far I am able to build my app for both Qt5 and Qt6 but maybe it is time to move forward.

        @artwaw You are probably right, I need really light and fast solution, it is of course no problem to run the application on M1 but the target is to be able to run it on RPi2.

        artwawA 1 Reply Last reply
        0
        • K KejPi

          @DerReisende said in Random application crash on Apple Silicon M1 (Qt 6.2.3):

          What about using move semantics (std::move)? You should be able to move your RadioControlEvent in there and later move it out of the queue. But it would then require a move constructor.

          Yes, but this implies Qt6, so far I am able to build my app for both Qt5 and Qt6 but maybe it is time to move forward.

          @artwaw You are probably right, I need really light and fast solution, it is of course no problem to run the application on M1 but the target is to be able to run it on RPi2.

          artwawA Offline
          artwawA Offline
          artwaw
          wrote on last edited by
          #39

          @KejPi QList and QQueue are lightweight, at least claim to be in the documentation. I never had memory problems on raspi, then again I never did anything that would strain the resources on raspi2.

          Having said that I trust there more experienced persons in this thread that would be able to judge if QList/Queue is the way to go in terms of usability or not.

          For more information please re-read.

          Kind Regards,
          Artur

          D 1 Reply Last reply
          0
          • artwawA artwaw

            @KejPi QList and QQueue are lightweight, at least claim to be in the documentation. I never had memory problems on raspi, then again I never did anything that would strain the resources on raspi2.

            Having said that I trust there more experienced persons in this thread that would be able to judge if QList/Queue is the way to go in terms of usability or not.

            D Offline
            D Offline
            DerReisende
            wrote on last edited by
            #40

            @artwaw QList is reentrant but not thread-safe. At least it is not mentioned in the docs and there are several questions over at stackoverflow.

            artwawA 1 Reply Last reply
            0
            • D DerReisende

              @artwaw QList is reentrant but not thread-safe. At least it is not mentioned in the docs and there are several questions over at stackoverflow.

              artwawA Offline
              artwawA Offline
              artwaw
              wrote on last edited by
              #41

              @DerReisende It is confusing, I agree, however I considered the documentation before posting (and asking if someone knows better, I also wrote "to some extent" as I am not certain myself):

              • QQueue is based on QList;
              • documentation to the class links to the chapter about Qt's container classes https://doc.qt.io/qt-6/containers.html where we have:
              they are thread-safe in situations where they are used as read-only containers by all threads used to access them.
              
              • in the sentence above there is a link to threat-safe https://doc.qt.io/qt-6/threads-reentrancy.html which doesn't shed much lite on this particular class.

              So I don't know. My limited experience with background thread passing data to QQueue in the main thread did not seem to fail.

              For more information please re-read.

              Kind Regards,
              Artur

              1 Reply Last reply
              0
              • K Offline
                K Offline
                KejPi
                wrote on last edited by KejPi
                #42

                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.

                S 1 Reply Last reply
                2
                • K KejPi

                  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.

                  S Offline
                  S Offline
                  sultan
                  wrote on last edited by sultan
                  #43

                  @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
                  
                  1 Reply Last reply
                  1
                  • S Offline
                    S Offline
                    sultan
                    wrote on last edited by sultan
                    #44

                    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.

                    K 1 Reply Last reply
                    0
                    • S Offline
                      S Offline
                      sultan
                      wrote on last edited by
                      #45

                      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'
                      
                      1 Reply Last reply
                      0
                      • J.HilkJ Offline
                        J.HilkJ Offline
                        J.Hilk
                        Moderators
                        wrote on last edited by
                        #46

                        Ok, seems like a potential bug with the latest macOS on M1 arch,

                        have you guys tried and reproduced it with a minimal example?


                        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                        Q: What's that?
                        A: It's blue light.
                        Q: What does it do?
                        A: It turns blue.

                        1 Reply Last reply
                        0
                        • S sultan

                          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.

                          K Offline
                          K Offline
                          KejPi
                          wrote on last edited by
                          #47

                          @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.

                          1 Reply Last reply
                          0
                          • S Offline
                            S Offline
                            sultan
                            wrote on last edited by sultan
                            #48

                            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.

                            K 1 Reply Last reply
                            0
                            • S sultan

                              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.

                              K Offline
                              K Offline
                              KejPi
                              wrote on last edited by
                              #49

                              @sultan Yes, this is aligned with my observations. It happens very frequently when I boot my laptop and in time it is less frequent

                              1 Reply Last reply
                              1
                              • K Offline
                                K Offline
                                KejPi
                                wrote on last edited by KejPi
                                #50

                                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.

                                S 1 Reply Last reply
                                1
                                • K KejPi

                                  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.

                                  S Offline
                                  S Offline
                                  sultan
                                  wrote on last edited by
                                  #51

                                  @KejPi My application uses libaravis from homebrew, which depends on libusb (also from homebrew).

                                  K 1 Reply Last reply
                                  0
                                  • S sultan

                                    @KejPi My application uses libaravis from homebrew, which depends on libusb (also from homebrew).

                                    K Offline
                                    K Offline
                                    KejPi
                                    wrote on last edited by KejPi
                                    #52

                                    @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 :-(

                                    S 1 Reply Last reply
                                    1
                                    • K KejPi

                                      @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 :-(

                                      S Offline
                                      S Offline
                                      sultan
                                      wrote on last edited by
                                      #53

                                      @KejPi I’ll try that out when I get some time (it’s a side project of mine). I could also diff the resulting library binaries if indeed that prevents the crashes.

                                      1 Reply Last reply
                                      0
                                      • C Offline
                                        C Offline
                                        CodeTreeHouse
                                        wrote on last edited by
                                        #54

                                        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)
                                        
                                        1 Reply Last reply
                                        1
                                        • S Offline
                                          S Offline
                                          sultan
                                          wrote on last edited by
                                          #55

                                          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.

                                          D 1 Reply Last reply
                                          0

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved