Hi Carlos.

On Fri, Dec 03, 2010 at 11:35:58AM -0500, Carlos Smith wrote:
> We are very happy with QtCreator, it is a very nice piece of work.  We
> are running the QtCreator 2.1.0 rc1 (though we've been seeing this as
> far back as 2.0 when we switched from Eclipse CDT to QtCreator) and Qt
> 4.7 and 4.7.1, on Windows 7 32 bit using the mingw toolchain provided
> with Qt.
> 
> However, we are having big problems with gdb crashing at apparently
> random times while we are debugging.  This is unfortunately making us
> doubt the viability of depending on QtCreator going forward because we
> need a reliable debugger and gdb doesn't seem to be so.
> And we moved from 2.0 to 2.1 beta and rc in the hopes that the gdb
> crashing would be fixed.

If gdb crashes changing the Creator version should not help, unless
the new version really triggers other codepaths due to reorganizations
or such.

You'd have to play around with replacing gdb itself. I have seen
rumours that MinGW themselves nowadays has a python enabled version
of gdb 7.2 (Google suggests http://qp-gcc.googlecode.com/files/gdb-7.2.7z) 
but I haven't verified that so far.
 
> I have read Andre's blogs about Creator and the debugger, gbd, python,
> and CDB.  And CDB doesn't look like a viable alternative either since
> it apparently has its own issues.
> 
> We have not been entering bugs on each gdb crash because between us
> they would be at least several a day and there is no correlation we
> can find.  Sometimes that app is just running and we are looking at
> the code and it goes down!  Should report a bug for each and every
> crash?  Do you need the entire log?  Yesterday one engineer had 7 gdb
> crashes (all access violations), but we have logs for all of those.

I need at least _one_ full log. More won't hurt.
 
> As far as I can tell we are running Qt "straight out of the box",
> building and running with the provided mingw toolchain, using the
> provided gdb-i686-pc-mingw32.exe that comes with Creator.
> 
> I see at gnu.org that there is a 7.2 version of gdb, does anyone know
> if this is more stable?  If it were, I'd have thought that the Trolls
> would be using that instead of 7.1.

Both 7.1 and 7.2 are fairly robust on Linux. In fact, I am happy with
what I see there. They have different sets of bugs, though, and there is
no released version of Qt Creator with a full set of workarounds for all
known 7.2 bugs. So 7.1 is actually a good choice. I think 7.2 will be
good with the Creator 2.1 release, not now (due to a recently discovered
problem with template parameters). As a rule of thumb it's pretty
straightforward to work around a bug as soon as it is known.

That is on _Linux_.

gdb on Windows is a completely different beast. At the time we shipped
Creator 2.0.x there was to my best knowledge not a single working python
enabled version, that's why we built and shipped one ourselves. This
sort of worked, but it was based on a more or less random CVS snapshot,
and I am by now aware of at least one bad performance issue of that specific
version.

> Is there any hope of this stabilizing?  When we were using Eclipse CDT
> gdb was the weak link there as well.  Does anyone have any tips on a
> more stable configuration?  We'd really hate to move from QtCreator,
> it's a very nice environment.

gdb is the only viable option to debug gcc compiled binaries, changing
frontends can only help in stability matters if the other frontend 
does not trigger the "bad" paths. That would be mostly luck, though.
[Well, to a degree it might be more then pure luck as Creator does 
a lot of things other gdb frontends don't do, so it's somewhat off
the well-trodden paths]

In any case, I'd personally prefer to see full bug reports and fix or
workaround the problems as we learn of them. Fixing gdb upstream is also
possible nowadays, but that requires the problems to be identified, too.

Andre'
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-creator

Reply via email to