[Qt-creator] Expanding a C string in the debugger takes forever?

[André Pönitz]

On Tue, May 22, 2012 at 09:04:53AM -0700, Bryce Schober wrote:
> 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)

gdb 7.1 is not perfect, but should be good enough for Creator up to
version 2.5. Ubuntu's build also uses Python.

> 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.

Easy use of different toolchains from within Qt Creator is certainly part of
Qt Creator's "main mission". If you have some something special in mind
that deserves improvement, please state it on bugreports.qt-project.org, or
maybe even check out the wip/profile branch.

>     > Is there some way I can set the default char-array interpretation to
>     > not blow up on my like this?
> 
> 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.

They are not specific to the length of the array. See the 'stripForFormat'
function in watchhandler.cpp.

Andre'