| Summary: | Crash on CMake project load | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Teo Mrnjavac <teo> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | cfeck, david.nolden.kde, stompdagger1 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Teo Mrnjavac
2009-06-13 15:09:33 UTC
Is it possible that you just ran out of memory? I've successfully imported full amarok right now. I'd say it's unlikely, I have 3GB of RAM on the laptop on which I have this issue. Plus, my desktop machine runs KDE 4.2.3 and the same revision of KDevelop doesn't die there. same here on kde4.2.4, 2 gigs of ram, the project was opened by previous version of kdevelop 4 any news? currently I cannot program due to this bug... great job! last svn sync (few minutes ago) solved the problem :) Not fixed for me as of 988551 hmm, the original backtrace looks like 197097, Teo are you using glibs 2.10 too? glibc 2.10.1 here, on Archlinux Ok, thanks. If you look at 197097 you'll see (towards the end) that the new glibc is quite a bit more eager when trying to find memory corruptions. Apparently that doesn't play too well with Qt and KDE. There's also a way posted to work around that (by disabling these eager checks in libc) and that workaround is also implemented for 4.3 release in startkde. *** This bug has been marked as a duplicate of bug 197097 *** well I use glibc 2.10.1 and I have no problems Thanks, MALLOC_CHECK_=1 seems to fix it for me. Is it safe to export it system-wide? This is not a duplicate. The crash happens in CppPreprocessEnvironment::merge (thread 2), the XIO error is the result of that crash (X11 socket killed). Changing the malloc debug options only ignores references to freed memory. If this bug is fixed in kdevelop, please mark as resolved. needs better backtrace. The relevant code doesn't call malloc directly, but uses a set class (thats AFAIK from google, so would be upstream). closing as upstream, the relevant code is not from us and we won't be fixing it. |