[Qt-creator] Debugging in QtCreator only shows disassembly

[i***@eraalaska.net]

I recently upgraded my computer to Mac OS X 10.11 (El Capitan), and Qt to 5.5.1 (from 5.4.1). After overcoming the usual frustration with getting the new application to launch (can't find platform plugin "cocoa" available platforms are: cocoa), I went about trying to debug my latest issue. But there I ran into a problem: Qt Creator isn't showing my code, but only the disassembly. Actually, it's not honoring my breakpoints either, the only way I can get it to go into the debugger at all is to hit the pause button. Once paused, I can see in the call stack the function in my code it is currently executing (I think I have an infinite loop or the like), but I can't see where in the file it is since all it shows is the disassembly. How can I get the debugger working again?

See the attached screen shot for the issue. The calculatePayPeriods() function is one I wrote, defined in the utilities.cpp file. I also tried going back to Qt 5.4 and an older version of Qt Creator, but neither of those helped any.

-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
[phone]
-----------------------------------------------

[i***@eraalaska.net]

Post by i***@eraalaska.net
See the attached screen shot for the issue. The calculatePayPeriods()
function is one I wrote, defined in the utilities.cpp file. I also tried
going back to Qt 5.4 and an older version of Qt Creator, but neither of
those helped any.

Does that change if you switch on
"Use debug version of frameworks (DYLD_IMAGE_SUFFIX=_debug)"
in your project's Run settings?

Doesn't appear to, no. Breakpoints are still ignored, and hitting the pause button still just drops me into the disassembler view, even once I have selected my function.

-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
[phone]
-----------------------------------------------

Andre'

[i***@eraalaska.net]

Post by i***@eraalaska.net

Post by i***@eraalaska.net
See the attached screen shot for the issue. The calculatePayPeriods()
function is one I wrote, defined in the utilities.cpp file. I also tried
going back to Qt 5.4 and an older version of Qt Creator, but neither of
those helped any.

Does that change if you switch on
"Use debug version of frameworks (DYLD_IMAGE_SUFFIX=_debug)"
in your project's Run settings?

Doesn't appear to, no. Breakpoints are still ignored, and hitting the pause
button still just drops me into the disassembler view, even once I have
selected my function.

This pretty much sounds like your executable is not compiled with
debug information.

Sort of sounds that way, yeah. Which of course begs the question of why?

Can you double-check this is indeed a debug build, and perhaps show
the contents of the "Compile Output" pane of a clean re-build?

Indeed it is a debug build, unless I am missing something. The attached text file contains the compile output of the latest run.

Note that I am using g++ rather than clang++ - I switched after reading a stack overflow answer where someone else reported similar symptoms, and success by switching. As it didn't seem to help in my case, I'll probably switch back.

[Ziller Eike]

Post by i***@eraalaska.net

Post by i***@eraalaska.net

Post by i***@eraalaska.net
See the attached screen shot for the issue. The calculatePayPeriods()
function is one I wrote, defined in the utilities.cpp file. I also tried
going back to Qt 5.4 and an older version of Qt Creator, but neither of
those helped any.

Does that change if you switch on
"Use debug version of frameworks (DYLD_IMAGE_SUFFIX=_debug)"
in your project's Run settings?

Doesn't appear to, no. Breakpoints are still ignored, and hitting the pause
button still just drops me into the disassembler view, even once I have
selected my function.

This pretty much sounds like your executable is not compiled with
debug information.

Sort of sounds that way, yeah. Which of course begs the question of why?

Can you double-check this is indeed a debug build, and perhaps show
the contents of the "Compile Output" pane of a clean re-build?

Indeed it is a debug build, unless I am missing something. The attached text file contains the compile output of the latest run.
Note that I am using g++ rather than clang++ - I switched after reading a stack overflow answer where someone else reported similar symptoms, and success by switching. As it didn't seem to help in my case, I'll probably switch back.

Since Clang is the only really supported compiler by Apple nowadays, you should really use that.
I suppose you tried a complete rebuild? If you happen to use ccache you should probably also try clearing your cache (ccache -C ?).

You can check how the debug info in an object file looks like with ‘dwarfdump’. Note that on OS X the debug info stays in the .o files if you do not use dsymutil after your build to extract it from them, so should avoid deleting them. And avoid moving them away. Though, for some things they fall back to use Spotlight for finding things (e.g. if you extract the debug info with dsymutil, afaik Spotlight is used to find the .dsym bundle the corresponds to your binary). Which actually might break if you are working on a volume that is excluded from Spotlight indexing.

I remember that using distcc also lead to the remotely compiled files having broken debug info (the paths to the sources in the debug info was wrong) because Clang made stupid assumptions. Haven’t checked that for a while though.

Br, Eike

Post by i***@eraalaska.net
<compileOutput.txt>
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
[phone]
-----------------------------------------------

Andre'

_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller, Senior Software Engineer - The Qt Company GmbH

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

[i***@eraalaska.net]

Post by Ziller Eike

Post by i***@eraalaska.net

Post by i***@eraalaska.net

Post by i***@eraalaska.net
See the attached screen shot for the issue. The calculatePayPeriods()
function is one I wrote, defined in the utilities.cpp file. I also tried
going back to Qt 5.4 and an older version of Qt Creator, but neither of
those helped any.

Does that change if you switch on
"Use debug version of frameworks (DYLD_IMAGE_SUFFIX=_debug)"
in your project's Run settings?

Doesn't appear to, no. Breakpoints are still ignored, and hitting the pause
button still just drops me into the disassembler view, even once I have
selected my function.

This pretty much sounds like your executable is not compiled with
debug information.

Sort of sounds that way, yeah. Which of course begs the question of why?

Can you double-check this is indeed a debug build, and perhaps show
the contents of the "Compile Output" pane of a clean re-build?

Indeed it is a debug build, unless I am missing something. The attached text file contains the compile output of the latest run.
Note that I am using g++ rather than clang++ - I switched after reading a stack overflow answer where someone else reported similar symptoms, and success by switching. As it didn't seem to help in my case, I'll probably switch back.

Since Clang is the only really supported compiler by Apple nowadays, you should really use that.
I suppose you tried a complete rebuild? If you happen to use ccache you should probably also try clearing your cache (ccache -C ?).
You can check how the debug info in an object file looks like with ‘dwarfdump’. Note that on OS X the debug info stays in the .o files if you do not use dsymutil after your build to extract it from them, so should avoid deleting them. And avoid moving them away. Though, for some things they fall back to use Spotlight for finding things (e.g. if you extract the debug info with dsymutil, afaik Spotlight is used to find the .dsym bundle the corresponds to your binary). Which actually might break if you are working on a volume that is excluded from Spotlight indexing.
I remember that using distcc also lead to the remotely compiled files having broken debug info (the paths to the sources in the debug info was wrong) because Clang made stupid assumptions. Haven’t checked that for a while though.
Br, Eike

It would appear that the problem lies with running the macdeployqt script after build. If I don't run it, then I can debug my app - except that my app needs to be sandboxed, and if I sandbox the app but DON'T run macdeployqt, then the app crashes - probably because it doesn't have read access to the Qt libraries. Without sandboxing, I get weird behavior (specifically, it appears to be getting some settings from SOMEWHERE - using QSettings -, but for the life of me I can't figure out where), and it's not really a valid test anyway. So I'm a bit stumped here - unless I can somehow modify macdeployqt to prevent breaking debugging?

Post by Ziller Eike

Post by i***@eraalaska.net
<compileOutput.txt>
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
[phone]
-----------------------------------------------

Andre'

_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

--
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

[Steve Atkins]

Post by i***@eraalaska.net
It would appear that the problem lies with running the macdeployqt script after build. If I don't run it, then I can debug my app - except that my app needs to be sandboxed, and if I sandbox the app but DON'T run macdeployqt, then the app crashes - probably because it doesn't have read access to the Qt libraries. Without sandboxing, I get weird behavior (specifically, it appears to be getting some settings from SOMEWHERE - using QSettings -, but for the life of me I can't figure out where), and it's not really a valid test anyway. So I'm a bit stumped here - unless I can somehow modify macdeployqt to prevent breaking debugging?

macdeployqt --help says:

-no-strip : Don't run 'strip' on the binaries
-use-debug-libs : Deploy with debug versions of frameworks and plugins (implies -no-strip)

Cheers,
Steve

[Ziller Eike]

Post by Steve Atkins

Post by i***@eraalaska.net
It would appear that the problem lies with running the macdeployqt script after build. If I don't run it, then I can debug my app - except that my app needs to be sandboxed, and if I sandbox the app but DON'T run macdeployqt, then the app crashes - probably because it doesn't have read access to the Qt libraries. Without sandboxing, I get weird behavior (specifically, it appears to be getting some settings from SOMEWHERE - using QSettings -, but for the life of me I can't figure out where), and it's not really a valid test anyway. So I'm a bit stumped here - unless I can somehow modify macdeployqt to prevent breaking debugging?

-no-strip : Don't run 'strip' on the binaries
-use-debug-libs : Deploy with debug versions of frameworks and plugins (implies -no-strip)

And/or running dsymutil on your executable before macdeployqt, to save the debug info, might help too.

--
Eike Ziller, Senior Software Engineer - The Qt Company GmbH

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

[Israel Brewster]

Post by Steve Atkins

Post by i***@eraalaska.net
It would appear that the problem lies with running the macdeployqt script after build. If I don't run it, then I can debug my app - except that my app needs to be sandboxed, and if I sandbox the app but DON'T run macdeployqt, then the app crashes - probably because it doesn't have read access to the Qt libraries. Without sandboxing, I get weird behavior (specifically, it appears to be getting some settings from SOMEWHERE - using QSettings -, but for the life of me I can't figure out where), and it's not really a valid test anyway. So I'm a bit stumped here - unless I can somehow modify macdeployqt to prevent breaking debugging?

-no-strip : Don't run 'strip' on the binaries
-use-debug-libs : Deploy with debug versions of frameworks and plugins (implies -no-strip)

Thanks. The -no-strip did the trick. For some reason -use-debug-libs prevent the package from being properly code signed, so the resulting application couldn't be sandboxed, but just using the -no-strip should be good enough.

Strange that I never had to do that before though. Oh well.

Post by Steve Atkins
Cheers,
Steve
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator