sal_vager

Okay @Clipperride, you're running out of memory but there doesn't seem to be a reason why as you have no mods and KSP should run in the memory you have. So something to try first is closing any other programs while running KSP to leave more RAM for your Kerbals. You have this message as well, just before the crash. And the dxdiag says your driver is from 2010 same as your laptop, so it might help to update it, but I cannot find your model on HP's website, or drivers for your processor on Intels site, it's showing me Linux drivers so maybe you can see drivers for Windows. Here's the main Intel driver page, supposedly they will work for you, but none list your CPU so I don't know which one will work.

Hi @Clipperride, the crash log is actually rather unhelpful, sorry The files that will tell us the most are the KSP.log in the Kerbal Space Program folder and the output_log.txt in KSP_Data. If you also run dxdiag from the start menu and save the hardware report that will help too. You could put these on dropbox.com or post them here in spoiler tags, using the eye button on the editor.

Extra entrant needed! All the entrants so far have been great, but one kind of test was missing and the devs have asked for it specifically. They need an ISRU setup that causes KSP to slow down, we're talking a big base here, multiple sections in close proximity (200m), lots of drills and converters, fuel cells and radiators, the works! It can be anywhere you like, so lets see what you can do

You're older than me... @Deddly!

YES! Next..... @NecroBones!

Sorry I mean the Steam files that come with KSP. Beale has a similar issue and using another file helped for a bit, unfortunately I don't have one of these controllers to test it. Does Steam let you create your own profile for KSP?

I don't think reinstalling will solve this so leave that as a last resort, I don't think borderless mode will do it either to be honest. It seems to be a driver issue, maybe the Steam dll files from another game will work?

Personally I'm glad we have a release on Linux, according to Steam Linux accounts for 0.81% of their users, even OS X is only 3.37%. Squad began to support KSP on Linux in early 2013 when exporting to Linux became stable enough in Unity, while we've only really seen a lot of attention towards Linux from the major players (Valve etc) much more recently. Fact is there's differences between the three platforms, OS X is based on Unix for example and Linux is 'Unix like' but is not the same. This means your Windows project very likely won't just work when exported to another platform and especially when it's not run on a supported version of that platform, Unity is good but it cannot perform miracles, so the build scripts will need tweaking, things that break on one platform but not another need a good coat of looking at, and you need to cross your fingers. But things will break, as software is updated new issues will occur, as the systems they run on are updated new issues will occur, unfortunately the only path to no new bugs (unless there's some you've not found yet) is to run one version on one machine and never change it, that's how you end up with COBOL running the banks and Windows XP in your ATM. KSP is always being improved, so expect new bugs even as old ones are fixed.

Good to know, and useful for @Eleven Plus I just updated my driver and can confirm it's not that.

Well, you're not supposed to be able to see that It's not shading, it's transparency, that's the texture of the light on its mesh (the octagon) and normally the dark area is transparent, there's still some translucency so the alpha channel is there, otherwise it would be black. As you had a driver update I'd try installing the previous driver, as the new one may be interpreting the alpha layer incorrectly, also I see you're using visual mods, it would be worth checking in a stock install in case the texture was changed by a mod. I'm still on nvidia-361.45 as I have an older card, and I don't see this effect.

Let me test... Edit: Looks legit.

Nice idea, one that I think @KasperVld would have to implement though

Okay, we'll need some more info as it should just work, when you start KSp it makes a new KSP.log in the Kerbal Space Program folder and a Player.log in /home/username/.config/unity3d/Squad/Kerbal Space Program If you could upload these to dropbox.com for us that'd be great.

Hi @nickdanger3tb, can you could take a look here please, we'll need more information before we can help you.

"Never say never", there may be a way around it that'll stop KSP crashing on all three platforms, even if it means writing custom destroy() methods in c#

Nope lol! @WinkAllKerb''!!

If I must... Next up is @Deddly!

There's no ETA on 1.2, it's actually a forum rule not to ask So far in my search for the cause of the crash I keep coming back to this And the full crash message... Not all crashes show this, though most will when I set environment MALLOC_CHECK_ 2 but the others don't have a meaningful output, and it seems that free() on Linux doesn't handle things gracefully if called on the same location twice, as mallocs man page says... Windows and OS X seem to cope with this better and they crash less often, but Linux is less forgiving and quite happily lets the user or programmer break things. Unfortunately for us, Unity3D's built in methods and the garbage collector (GC) in Mono make calls to the memory allocation commands, including to free(), so if they are doing it wrong and are not calling *alloc() first, or if the custom version of Mono is bugged, or if the pointers are becoming corrupted we get to enjoy 'undefined behaviour'. So if this is the cause the next question is how can it be fixed? As Unity's Mono doesn't prevent calling free() twice on the same pointer it'd make sense to fix Mono so that this can't happen, this might already be fixed in newer versions of Mono, and now that Microsoft have released Mono/Xamarin under the MIT license Unity Technologies are free to upgrade to the latest version. Of course, this is moot if the ability to bork your own code by calling free() on an already freed pointer is a deliberate design decision. If the ability to segfault due to forgetting to call *alloc() before free() isn't a bug then it would fall to Unity Technologies to fix their Destroy() method, their call to the GC and anything else that frees memory. I think this would be trivial, as once you've freed memory it becomes available to the system as heap memory, you can't use that area again until you create another object that just happens to be allocated to the same spot in memory, so immediately after calling free() you null your pointer and move on, that way even if the GC starts half way through Destroy()ing objects in a list, if it hits a null pointer it will happily keep going. Assuming either of the above ever occur So what can Squad do? Replacing Mono is not an option as it is modified by Unity Technologies, 'normal' versions of Mono won't work with Unity, and modifying either Mono or Unity (source code access can be purchased, but it's intended for reference not modification, that's if it will even compile) could cause new issues that won't be eligible for support. That leaves trying to avoid situations where Unity calls free() twice, not easy when the GC can run at any time, where free() can be delayed, and where you have multiple threads, any two of which might be destroying objects at the same time. But they are trying.

This is a rather old thread guys...

I wish I had an answer for you @azander, but I do not know why this occurs. I stopped using KDE a few years ago specifically because it would crash when playing KSP, parts of the GUI would become unresponsive, then simply vanish, with the whole desktop becoming gradually more broken over time after having run KSP, I don't know if this still occurs. It'd be a workaround rather than a fix, but have you tried any other desktop environments?

Hi @Dwerto, can you please upload the full crash log, the output_log.txt and your dxdiag hardware report, thank you.

Nah that's meant to be fixed in a later version of Unity3D than is used by KSP 1.1.3 Another workaround is pulsenomore by kspflo which is essentially the same, available here.

In 1.1 and above a lot of work was done to improve performance by things such as the physics, this did not reduce the total memory used as caching things in memory uses a little more RAM, but provides a little more speed. 1.0 saw a memory reduction with the move to the .dds format for textures. Unfortunately you are trying to run a game that needs more than 2gb on a system that cannot provide it, going over that limit by just 1mb will cause KSP to crash. Reducing your texture setting will help, with all graphics settings reduced KSP should use about 1.9gb with a rocket on the launchpad. Forcing KSP to use OpenGL will help as well, as it will handle texture memory a little bit more efficiently than DirectX9, and using an operating system that doesn't restrict the user to 2gb for applications will also help avoid this. You could check your boot.ini for the /GB flag but I don't recommend this as you could cause Windows to fail to start. And please make sure you are using 1.1.3, you keep saying 1.1, if you are using 1.1 you are behind the current release and 1.1.3 may work for you.

Sorry we can't help you @T0ffel0k, it looks like you will have to wait for Microsoft to issue a fix.

@Xenro66, are you using the beta version of the Steam client? It may not work with the version of CSteamworks.dll provided with KSP.