Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt Creator and other tools
  4. Qt Creator fails to debug on MacOS if debugged is run with arguments
Forum Update on Monday, May 27th 2025

Qt Creator fails to debug on MacOS if debugged is run with arguments

Scheduled Pinned Locked Moved Solved Qt Creator and other tools
5 Posts 2 Posters 2.3k Views
  • 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.
  • E Offline
    E Offline
    Enmk
    wrote on 3 Nov 2018, 09:02 last edited by
    #1

    Hi! I am a big fan of Qt Creator, but there is one thing that bugs me:
    I can't debug a native app on MacOS if I specify command line arguments, without those debugging works just fine.

    Here all the details:
    I am building an open-source C++ library and C++ test driver program for that library on MacOS Vojave (version 10.14 (18A391)) with an open source version of Qt Creator (Qt Creator 4.7.2). The project is a CMake-based, not trivial but not too complicated, the build directory is outside of source tree, obviously.
    The kit I use for compiling is a "Desktop" one, configured automatically to GCC/LLDB, Qt itself is not installed.

    Here are all the versions of all stuff involved:

    $ /usr/bin/gcc --version
    Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
    Apple LLVM version 10.0.0 (clang-1000.11.45.5)
    Target: x86_64-apple-darwin18.0.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
    
    $ /usr/bin/g++ --version
    Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
    Apple LLVM version 10.0.0 (clang-1000.11.45.5)
    Target: x86_64-apple-darwin18.0.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
    
    $ /usr/bin/lldb --version
    lldb-1000.11.38.2
      Swift-4.2
    
     $ /usr/local/bin/cmake --version
    cmake version 3.11.4
    
    CMake suite maintained and supported by Kitware (kitware.com/cmake).
    

    It builds and runs gorgeously, and I even can debug my test driver program. Unless I specify an argument to in Projects/Build and Run/Desktop. Then it fails to stop at any break point, and it appears like the debugged itself wasn't ran at all, since "Application Output" pane simply says:

    11:33:42: Debugging starts
    11:33:45: Debugging has finished
    

    While if I just run (not debug) there is a lot of output.

    I first noticed this issue when I moved to MacOS as my primary environment from Linux about a year ago with Qt Creator 4.5 or something, and MacOS 10.12 or 10.13 (not sure), and the issue is still there with the most recent version of OS and Qt Creator.

    ![2_1541235714716_Screen Shot 2018-11-03 at 12.00.38.png](Uploading 100%) ![1_1541235714716_Screen Shot 2018-11-03 at 12.00.32.png](Uploading 100%) ![0_1541235714716_Screen Shot 2018-11-03 at 12.00.20.png](Uploading 100%)

    A 1 Reply Last reply 3 Nov 2018, 10:08
    0
    • E Enmk
      3 Nov 2018, 09:02

      Hi! I am a big fan of Qt Creator, but there is one thing that bugs me:
      I can't debug a native app on MacOS if I specify command line arguments, without those debugging works just fine.

      Here all the details:
      I am building an open-source C++ library and C++ test driver program for that library on MacOS Vojave (version 10.14 (18A391)) with an open source version of Qt Creator (Qt Creator 4.7.2). The project is a CMake-based, not trivial but not too complicated, the build directory is outside of source tree, obviously.
      The kit I use for compiling is a "Desktop" one, configured automatically to GCC/LLDB, Qt itself is not installed.

      Here are all the versions of all stuff involved:

      $ /usr/bin/gcc --version
      Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
      Apple LLVM version 10.0.0 (clang-1000.11.45.5)
      Target: x86_64-apple-darwin18.0.0
      Thread model: posix
      InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
      
      $ /usr/bin/g++ --version
      Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
      Apple LLVM version 10.0.0 (clang-1000.11.45.5)
      Target: x86_64-apple-darwin18.0.0
      Thread model: posix
      InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
      
      $ /usr/bin/lldb --version
      lldb-1000.11.38.2
        Swift-4.2
      
       $ /usr/local/bin/cmake --version
      cmake version 3.11.4
      
      CMake suite maintained and supported by Kitware (kitware.com/cmake).
      

      It builds and runs gorgeously, and I even can debug my test driver program. Unless I specify an argument to in Projects/Build and Run/Desktop. Then it fails to stop at any break point, and it appears like the debugged itself wasn't ran at all, since "Application Output" pane simply says:

      11:33:42: Debugging starts
      11:33:45: Debugging has finished
      

      While if I just run (not debug) there is a lot of output.

      I first noticed this issue when I moved to MacOS as my primary environment from Linux about a year ago with Qt Creator 4.5 or something, and MacOS 10.12 or 10.13 (not sure), and the issue is still there with the most recent version of OS and Qt Creator.

      ![2_1541235714716_Screen Shot 2018-11-03 at 12.00.38.png](Uploading 100%) ![1_1541235714716_Screen Shot 2018-11-03 at 12.00.32.png](Uploading 100%) ![0_1541235714716_Screen Shot 2018-11-03 at 12.00.20.png](Uploading 100%)

      A Offline
      A Offline
      aha_1980
      Lifetime Qt Champion
      wrote on 3 Nov 2018, 10:08 last edited by
      #2

      @Enmk hi, that sounds strange. does Windows > Views > Debugger Log shows some more info? probably some parameter passing or quoting went wrong.

      Qt has to stay free or it will die.

      E 1 Reply Last reply 4 Nov 2018, 12:26
      1
      • A aha_1980
        3 Nov 2018, 10:08

        @Enmk hi, that sounds strange. does Windows > Views > Debugger Log shows some more info? probably some parameter passing or quoting went wrong.

        E Offline
        E Offline
        Enmk
        wrote on 4 Nov 2018, 12:26 last edited by
        #3

        @aha_1980 Hi, thank you for pointers!

        Well, the Debugger Log clearly shows that there is an error:

        (lldb) script theDumper.runEngine({"token":22})
        
        >@
        >success="0",error={type="1",status="process exited with status -1 (cannot attach to process due to System Integrity Protection)",code="4294967295",desc="error: process exited with status -1 (cannot attach to process due to System Integrity Protection)"}@
        >@
        >state="enginerunfailed"@
        dNOTE: ENGINE RUN FAILED
        sRun failed.
        dState changed from EngineRunRequested(4) to EngineRunFailed(5) [master]
        dState changed from EngineRunFailed(5) to EngineShutdownRequested(15) [master]
        dCALL: SHUTDOWN ENGINE
        dNOTE: ENGINE SHUTDOWN FINISHED
        dState changed from EngineShutdownRequested(15) to EngineShutdownFinished(16) [master]
        dState changed from EngineShutdownFinished(16) to DebuggerFinished(17) [master]
        sDebugger finished.
        

        I believe that might be due to funny way Qt Creator launches debuggee (is it an immediate child of debugger?)
        Anyhow, it is quite surprising that debugging a process with no command line arguments works as expected.

        A 1 Reply Last reply 4 Nov 2018, 15:56
        0
        • E Enmk
          4 Nov 2018, 12:26

          @aha_1980 Hi, thank you for pointers!

          Well, the Debugger Log clearly shows that there is an error:

          (lldb) script theDumper.runEngine({"token":22})
          
          >@
          >success="0",error={type="1",status="process exited with status -1 (cannot attach to process due to System Integrity Protection)",code="4294967295",desc="error: process exited with status -1 (cannot attach to process due to System Integrity Protection)"}@
          >@
          >state="enginerunfailed"@
          dNOTE: ENGINE RUN FAILED
          sRun failed.
          dState changed from EngineRunRequested(4) to EngineRunFailed(5) [master]
          dState changed from EngineRunFailed(5) to EngineShutdownRequested(15) [master]
          dCALL: SHUTDOWN ENGINE
          dNOTE: ENGINE SHUTDOWN FINISHED
          dState changed from EngineShutdownRequested(15) to EngineShutdownFinished(16) [master]
          dState changed from EngineShutdownFinished(16) to DebuggerFinished(17) [master]
          sDebugger finished.
          

          I believe that might be due to funny way Qt Creator launches debuggee (is it an immediate child of debugger?)
          Anyhow, it is quite surprising that debugging a process with no command line arguments works as expected.

          A Offline
          A Offline
          aha_1980
          Lifetime Qt Champion
          wrote on 4 Nov 2018, 15:56 last edited by
          #4

          @Enmk,

          That one:

          (cannot attach to process due to System Integrity Protection)

          looks very strange, but I'm no mac user, so I cannot say how things are supposed to work.

          I suggest you to try the 4.8 beta first (you can install it with the online installer), and if that behaves the same, you should create a bugreport at bugreports.qt.io. Attach the debugger log (both sides) to the report and wait what the devs say.

          Regards

          Qt has to stay free or it will die.

          1 Reply Last reply
          1
          • A Offline
            A Offline
            aha_1980
            Lifetime Qt Champion
            wrote on 5 Nov 2018, 08:12 last edited by
            #5

            Continued as QTCREATORBUG-21433, therefore setting this here as SOLVED.

            Qt has to stay free or it will die.

            1 Reply Last reply
            2

            1/5

            3 Nov 2018, 09:02

            • Login

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