Version: 3.0.0 (using KDE 3.2.90 (CVS >= 20040117), yes) Compiler: gcc version 3.3.3 20040125 (prerelease) (Debian) OS: Linux (i686) release 2.4.23-1-k7 When I try to complete a Qt or KDE type with a fresh PCS i get a crash every time. The error is an assert in kdevelop/lib/catalog/gcatalog.tcc on line 364. Now was is VERY strange is the error returned is -30978. This is #define DB_RUNRECOVERY (-30978)/* Panic return. */ in the dbm support file. Now this ERROR should have never happened according to the docs. Worse we assert on errors here instead of handling them. We ensure that the user will always trash the app if anything goes wrong. This should at least be fixed...
I did some more reading and while it's true that the failing call, according to the api docs, should not be able to return this error, I also found: "Once DB_RUNRECOVERY is returned by any interface, it will be returned from all subsequent Berkeley DB calls made..." It seems likely we have have an (ignored) error condition earlier and the real problem is probably not even close to the crashpoint. I also note that our "Requirements" page (http://www.kdevelop.org/index.html?filename=requirements.html) lists "Berkley DB >= 3.0 and <= 4.1" (anyone know who put it there? the configure test apparently accepts anything >3.0.) and I believe Ian is running the latest stable version (4.2.52?)
*** Bug 71450 has been marked as a duplicate of this bug. ***
I've put it there bacause a user had problems using a newer DB version, but then downgraded and the problems where gone.
OK.. we need to look into this deeper. If we really always bomb with 4.2.x versions we should put in a runtime check for bdb version and refuse to use it if the check fails. geiseri, could you possibly downgrade your bdb to some 4.1.x version and try to repeat the case? We need to update the configure check too, if this issue persists.
I dropped back to 4.1... bad news while Qt works KDE-libs still blows up. This is kinda funky, because id think both would be working or failing. One other thing that confused me. If I uncheck a database it still crashes with the same backtrace. It seems that the only way to "fix" it is to remove the pcs manually... This should be an option. As a side note "WHY THE HELL DO WE HAVE ASSERTS IN PRODUCTION CODE?!" ;) If we are going to assert that means a) we are going to fix this bug before release or B) we hate all human life, espesially the kind who has yet to save their work before command completion kill it.
*** Bug 76233 has been marked as a duplicate of this bug. ***
*** Bug 81750 has been marked as a duplicate of this bug. ***
*** Bug 82125 has been marked as a duplicate of this bug. ***
Had seem problem (Suse 9.1, cvs tarball 24-05-04, BDB4.2.52). Recompiled with DB4.0, now code completion works fine again. Please add at least a check in configure.
Fedora Core 2 uses db 4.2, this is a big problem for me, I can't use code completion :( but I compiled kdevelop with db4.1 and don't crashes.
this worked: Suse 9.1, cvs tarball xx-05-04, db 4.0 workes fine now: Suse 9.1, cvs tarball 02-06-04, db 4.2 ;)
correction: NOT cvs tarball 02-06-04, but version 3.0.3 works with db 4.2
*** Bug 83028 has been marked as a duplicate of this bug. ***
As we have now in cvs head local copy of bdb 3.2.9a which is know to work well, I'm closing this bug. Please test cvs version. In case of successful tests I will backport bdb copy to branch and we will release 3.0.5 version.
*** Bug 83403 has been marked as a duplicate of this bug. ***
*** Bug 87558 has been marked as a duplicate of this bug. ***