| Summary: | kdevelop always crashes on code completion of PCS stored data. | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | geiseri |
| Component: | Code completion | Assignee: | KDevelop Developers <kdevelop-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | bjoern.eschrich, fawad_lateef, gj, mcohen, post, weiland, xshock |
| Priority: | NOR | ||
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
geiseri
2004-02-09 02:17:40 UTC
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. *** |