Commit r1066661: "Make it possible to run kdevelop in gdb again"

David Nolden zwabel at
Mon Dec 28 19:57:08 UTC 2009

Am Montag 28 Dezember 2009 19:53:47 schrieb Andreas Pakulat:
> But then I can try to debug problems with the session-specific duchain
> directory.
> I'm starting to think that having the duchain in static code loaded
> before everything else is the real problem here. If that wasn't the case
> we wouldn't need this obscure env var and any extra process.

That would also mean that one couldn't use "IndexedIdentifier", 
"IndexedString", and all such duchain types statically, which would be a 
significant limitation for such cosmetic reasons.

You can always debug the kdevelop startup doing:
KDEV_SESSION_ID=... gdb kdevelop
(gdb) run

with the KDEV_SESSION_ID value read from "ls ~/.kdevduchain" or from the 
debug-output that kdevelop gives on every startup. And you would _only_ need 
that when debugging duchain-directory specific startup problems, for other 
cases we could have a simple "--nofork" option. Btw, startup problems that are 
specific to one duchain repository are very hard to debug anyway, as the whole 
repository is wiped automatically after 2 crashes.

More information about the KDevelop-devel mailing list