Qt Creator 2.7, empty Locals and Expressions view?
We are running Qt5 on our ARM device. On the ARM device we start gdbserver with the application we want to debug remotely.
On our development PC, we use the correct gdb version to connect to the gdbserver. Then we start the debugging and things like setting breakpoints and stepping all work fine, no problems there!
To show the stack when reaching a breakpoint we have to doubleclick on the 'thread' in the thread view manually, which seems a bit strange.
But our biggest problem is that no 'locals and expressions' are shown.. When using the gdb command 'info locals' in the 'debugger log' view we can clearly see that gdb knows about the locals. So it seems Qt creator is failing to display them.
Does anybody have an idea what is going wrong?
Please attach the debugger log (contents of right pane of Windows->View->Debugger Log). And please note that there aren't many Qt Creator developers attending this forum here, whereas the mailing list and the #qt-creator IRC channel on FreeNode are typically watched.
Was there ever a solution for this? I have the same issue.
Debug log is at http://pastebin.com/qW1bQLkt
It seems to be stuck with the 'bb' command not being found. What is 'bb'?
The poblem is "IOError: [Errno 13] Permission denied: '/usr/local/share/qtcreator/dumper/gbridge.py'". Does this file exist, and is it readable?
Same problem here. Did anybody find a solution for that problem?
[quote author="andrep" date="1367093487"] ... whereas the mailing list and the #qt-creator IRC channel on FreeNode are typically watched.[/quote]
Where are the mailing list? (Edit: as usual , post and found, http://lists.qt-project.org/ )
Thanks and best regards
I found this problem too. But, it 's not the same with yours.
gdb runs bb command ok. but nothing reply. it 's empty. as below:
&"bb options:fancy,autoderef,dyntype vars: expanded:return,local,watch,inspect typeformats: formats: watchers:\n"
<Rebuild Watchmodel 43>
Finished retrieving data
This might be the result of a "newer" GCC emitting debug information in a way that and "older" GDB does not understand. Which versions of both are you using?
Our problem was that the Desktop kit and Target kit were using the same Python. We workarounded it creating the PYTHONHOME variable on Desktop Kit and pointing it to /usr
Best regards and good luck,