| Summary: | importing linux kernel as Makefile-project causes crash | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Christian Parpart <trapni> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version: | 4.1.0 | ||
| Target Milestone: | 4.1.0 | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Christian Parpart
2010-11-02 13:25:29 UTC
looks like a out-of-memory assert, can you tell me what the konsole spits out on crash? Also: how much memory do you have available? I'd have to do some massif profiling to decrease the memory usage it seems... (In reply to comment #1) > looks like a out-of-memory assert, can you tell me what the konsole spits out > on crash? > > Also: how much memory do you have available? > > I'd have to do some massif profiling to decrease the memory usage it seems... Hey, I'm having 4GB RAM here on this machine, and 8GB RAM at home - on both it happens, the dump above is from here however, with the following infos (*WHILE* loading the linux-2.6): trapni@rocket ~ $ free -mt total used free shared buffers cached Mem: 3824 3250 573 0 0 1042 -/+ buffers/cache: 2208 1616 Swap: 4102 108 3993 Total: 7926 3358 4567 trapni@rocket ~ $ df -hT Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 452G 63G 390G 14% / /dev/root btrfs 452G 63G 390G 14% / rc-svcdir tmpfs 1.0M 136K 888K 14% /lib64/rc/init.d udev tmpfs 10M 272K 9.8M 3% /dev none tmpfs 1.9G 424K 1.9G 1% /dev/shm cachedir tmpfs 4.0M 4.0K 4.0M 1% /lib64/splash/cache trapni@rocket ~ $ mpstat -P ALL Linux 2.6.35-gentoo-r4 (rocket) 11/04/2010 _x86_64_ (4 CPU) 02:10:41 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:10:41 PM all 4.54 1.26 0.85 1.58 0.00 0.03 0.00 0.00 91.72 02:10:41 PM 0 7.57 1.16 1.42 2.04 0.00 0.12 0.00 0.00 87.69 02:10:41 PM 1 8.34 1.25 1.25 2.89 0.00 0.01 0.00 0.00 86.25 02:10:41 PM 2 1.28 1.32 0.34 0.55 0.00 0.00 0.00 0.00 96.52 02:10:41 PM 3 0.97 1.32 0.40 0.84 0.00 0.00 0.00 0.00 96.47 it looks like - while decreasing the desktop responsiviness alot, kdevelop doesn't seem to scale well across the CPUs. I also noticed alot of ENOSPC errors in the controlling terminal that belong to inotify; this looks like a limitation to file descriptors rather than no disk space, however, I think this could be increased automatically by a software by invoking setrlimit(RLIMIT_NOFILE, {8192, 8192}); or similar (would require root or some external supervisor or software-reboot, ...) UPDATE: this time (read: on second second start of kdevelop - after the initial project import crash) the load time were pure horror, system latency went up, practically unusuable system (required lots of patience). but in the end, it seemed to have loaded the project fully. I tried to open up some files but in the end killed the process due to its unresponsiveness. I'll give it a try at home again, however, here is the log dump: http://trapni.de/~trapni/kdevelop-linux-2.6.log.gz (9MB gzipped, 256MB plain!) you should disable all debug output you don't want (all?) launch kdebugdialog and deselect all (or at least kdevelop + kdevplatform). The log itself looks fine though, it happily parsed quite some files. I'll do some profiling later though. thanks for the bug report, I finally had the time to look at it and indeed, it was a serious (but easy to fix) problem. Please look forward to KDevelop 4.1.1 or built it from sources. many thanks :) |