Erant

Here the last lines of the KSP-Log. Before that there were a ton of kOS events, of course. ... [LOG 22:28:56.044] kOS: FlightControl Unbinding [LOG 22:28:56.044] kOS: FlightControl Unbound [LOG 22:28:56.044] kOS: Execution Broken [LOG 22:29:06.903] [PlanetariumCamera]: Focus: kOS_Launch_07 [LOG 22:29:13.129] Packing kOS_Launch_07 for orbit [LOG 22:29:34.308] Vessel kOS_Launch_07 Debris was on-rails at 1.0 atm pressure and was destroyed. Yeah, that's the same problem. It can manifest in ways other than an explicit "failed to allocate", depending on who did the allocation and wether they bothered to check the return value of malloc(). Most programmers don't. Your crashlog says the following: TOTAL, minus reserved VM space 3.7G Which means there is 3.7GB worth of virtual space allocated. The virtual space at this point is likely quite fragmented so malloc couldn't find a contiguous swath of memory to allocate whatever malloc requested, gave up and returned NULL. The programmer didn't check the return value, happily tried to dereference it and *crash*. Interesting little tidbit in your crashlog as well: Writable regions: Total=3.3G written=84.7M(3%) resident=2.1G(64%) swapped_out=16K(0%) unallocated=1.2G(36%) There is 1.2GB of virtual space that has absolutely nothing backing it. The memory has never been used, so the OS never bothered to actually back it with physical memory (but it's still mapped into your process, so it's eating virtual space). I did some more digging of my own (just to see if there was anything I could hack together that would relieve some of the virtual address space pressure), but it doesn't really look like there is anything being duplicated inside the address space. The IOKit shared memory segments that I referenced earlier are actually largely 2D textures. These end up mapped into VRAM (so, in video card RAM), and the KSP process. I am still a little confused about some of the larger shared memory mappings (There are several that are upwards of 10M, and one is +150M), but they're hard to identify with just Dtrace. I'm just going to wait until KSP gets updated, as playing like this isn't fun anymore. Looking around the forums, the Windows port doesn't seem to fare any better than the Mac OS X one does as far as random crashes goes...

This is exactly the problem. I've been looking at this for the better part of today, and I have come to the conclusion that while memory leaks could be part of the reason there are almost no true memory leaks. The 'leaks' utility only finds about ~5MB of truly leaked memory (no pointers to malloc-ed regions), and Instruments agrees. However, there is an extremely large amount of shared memory with IOKit, 1.3GB. Running: sudo dtrace -n 'fbt::*clientMemoryForType*:entry', finds many calls to: 245908 _ZN15IOAccelContext219clientMemoryForTypeEjPjPP18IOMemoryDescriptor:entry 255005 _ZN29IOFramebufferSharedUserClient19clientMemoryForTypeEjPjPP18IOMemoryDescriptor:entry Which will quickly fill up the virtual memory space. Fundamentally there isn't really a memory problem, and certainly not an actual physical memory problem. The problem is that many features were added recently that takes up a lot of virtual memory and IOKit is being very liberal with its shared memory usage. The only real solution to this problem is making KSP a 64 bit process. The developers can patch around the limit but that's not really fixing anything... vmmap says: REGION TYPE VIRTUAL =========== ======= CG backing stores 20.2M CG image 60K CG shared images 240K CoreUI image data 104K [B]IOKit 1.2G[/B] Kernel Alloc Once 4K MALLOC 1.1G see MALLOC ZONE table below MALLOC (admin) 64K MALLOC freed, no zone 12.4M Memory Tag 242 12K OpenCL 16K OpenGL GLSL 128K STACK GUARD 56.1M Stack 15.2M VM_ALLOCATE 450.1M VM_ALLOCATE (freed) 12K VM_ALLOCATE (reserved) 4K reserved VM address space (unallocated) __DATA 15.4M __GLSLBUILTINS 2588K __IMAGE 528K __LINKEDIT 50.2M __OBJC 2484K __TEXT 172.3M __UNICODE 544K mapped file 64.0M shared memory 68K =========== ======= TOTAL 3.2G TOTAL, minus reserved VM space 3.2G VIRTUAL ALLOCATION BYTES MALLOC ZONE SIZE COUNT ALLOCATED % FULL =========== ======= ========= ========= ====== DefaultMallocZone_0x157c000 688.0M 430535 640.8M 93% GFXMallocZone_0x1766000 446.1M 27621 380.5M 85% DispatchContinuations_0x1782000 8192K 107 7K 0% CoreGraphics_0x1809800 72K 626 13K 18% QuartzCore_0x9013a00 16K 2 112 0% =========== ======= ========= ========= ====== TOTAL 1.1G 458891 1.0G 89% Which is from the main screen. That only leaves about 800MB of virtual address space. I'd wager that the Windows and Linux ports suffer from the same problem, but just have less virtual address space pressure.