[Qt-creator] Expanding a C string in the debugger takes forever?
bryce.schober at gmail.com
Tue May 22 18:04:53 CEST 2012
On Mon, May 21, 2012 at 11:47 AM, André Pönitz <
andre.poenitz at mathematik.tu-chemnitz.de> wrote:
> Could you check where the 1.5 minutes are spend, i.e. before the
> response shows up in the log (pointing to the gdb side), or
> afterwards (pointing to the watch model)?
> > Are you interested in the full debugger log?
> Yes, please.
Wow, thanks for jogging my sleuthing ideas - I think you pointed me to the
problem. I went to reproduce this just now and wasn't able to - it turns
out that I'm in a different sandbox (different branch) for the project this
time. This project has its toolchain switched to a clone of the
auto-detected one (with a gdb 7.1 from ubuntu, don't know about python
support) whose gdb has been re-pointed to the one installed with the Qt SDK
(a gdb 7.3.1from nokia).
I guess my usage is outside the realm of Qt Creator's main mission (not
having anything to do with Qt development), but it's pretty awkward to
maintain a multitude of projects, all needing non-standard toolchain
setups, and having to propagate those manually to other users. I guess the
way that's handled in Qt Creator's main use case is by selecting the
appropriate SDK version for the project, and that being predictable across
installations, and without getting as sophisticated in setting up
consistent "SDKs" ourselves, it will remain difficult and manual.
> > Is there some way I can set the default char-array interpretation to
> > not blow up on my like this?
> The "per-type" format settings are persistent.
But in the case of char arrays, these per-type format settings are usually
unhelpful, because they're specific to the length of the array. And who
every wrote code with consistently sized char arrays anyway? ;-)
<>< <>< <><
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qt-creator