Saturday, 24 June 2017

QtCreator's debugger broken on Mac???


Problem

As the product of my client is running on both Windows and Mac, we have got our fair share of Mac bugs to be fixed. Yes, we really do, despite the fact that we are using Qt as our cross-platform portability layer! Write once, test everywhere, again... 😞

Unfortunately, we had repeatedly encountered problems with debugging. As we were using QtCreator* on Mac to do Qt-development, we were trying to use its (i.e. QtCreator's) debugger but unfortunately we ran into problems when trying to use breakpoints.

Namely, the debugger seemed to ignore the breaking points we set, as it didn't stop the execution for them! Interestingly, you could step through the code and reach every nook and cranny of it, but you cannot let it run and wait till a breakpoint will be hit. So we had to set our breakpoints directly with LLDB and debug there - no graphical GUI and IDE goodies.

It's needless to say, that this constituted a major obstacle in our quest to eradicate all bugs on Mac. After the annoyance level has hit the high-water mark, my two brave colleagues SaÅ¡a and Bojan came up with a solution which was quite surprising. I just want to share with you, my googling fellow-programmer, and with the rest of internet for the greater good...

Solution

It turned out, that the problem was due to the format of the debug information generated by qmake - it contained relative source file paths, like ../source.cpp. When used directly in LLDB, this didn't pose any problems, everything went well.

Unfortunately, when trying to set a breakpoint out of Qt-Creator, this started to be a issue, as Qt-Creator used full file paths when trying to set a breakpoint with LLDB. You see, file paths didn't match, this just couldn't work! For the sake of completeness it has to be mentioned that QtCreator does not have its own debugger - it just integrates Clang's LLDB and provides an comfortable GUI for it (but you knew it already, I guess...).

The solution was blatantly obvious - one just have to coerce qmake to create debug information containing absolute source file names. This can be done with the
QMAKE_PROJECT_DEPTH=0
option! Done and done!

The only problem is that this isn't an official option but an undocumented one! But it saved the day for us, so we will stay with it for the moment. If you want to read it, there's an interesting article "Undocumented QMake" on the Qt-Wiki. What it says about this special option is:
it seems this represents the number of sub folder that qmake refer to with relative paths (hardcoded is depth=4 in makefile.cpp) ...
As it seems, setting it to zero will force the usage of absolute paths.

Conclusion

As I said earlier, this all is due to SaÅ¡a (and Bojan) so don't give me any credit for that! I'm only the messenger.

As a last word: we are using Qt version 5.6.1 at the moment.

--
* with Clang as compiler and and its LLDB as debugger


4 comments:

  1. I have the same problem. I tried this solution and it didn't work for me. I compared the compile output. It did have the effect of removing relative paths from the compile command lines.

    It seems to me that there would also have to be a new linker command that would change the format of the debug information output in the executable.

    ReplyDelete
  2. I need to take back or amend my last comment.

    Creator and the project need a similar relationship to the boot volume. UNIX considers /Volumes/Boot Volume/xxx to be the same as /xxx

    So I had Qt on a different drive than the project. The project was on the boot volume, so it was /QT Projects/etc. for the compiler but Creator was seeing that as /Volumes/Boot Volume/QT Projects/etc.

    As soon as I put the project on the same drive as Qt Creator, it was working.

    ReplyDelete
  3. @David cool, I'm glad it worked out in the end!

    ReplyDelete
  4. I want to thank you for this blog. It definitely put me on the right solution.

    ReplyDelete