steve_v

Related, as it's mono that handles garbage collection for managed (read KSP/mods) code. There are performance issues with the way it does this, but it's not the same issue we're seeing here. So far indications are that this crashing has something to do with how mono allocates memory from the host OS, not how KSP allocates memory within mono, if that makes any sense.

Mono is the CLI (common language infrastructure) runtime that the C# code in KSP and mods execute within. It implements (most of) the .NET framework, and can run the same code without alteration on multiple platforms - this is why mods are generally OS agnostic. Essentially, it allows you to write code without knowing anything about the OS it's supposed to run on or dealing with low-level stuff like memory management, locking etc. Unity forked the open-source mono project some years ago (and their version is way behind upstream now) to use it as an in-game scripting/programming language. Squads part of KSP all runs in mono. There's a longer answer over on Unity answers, if you can be arsed reading it (WOT warning).

Ntdll.dll appearing in the stack traces means nothing more than "Something bad happened while KSP/Unity was interfacing with the OS." This is not too dissimilar to the crashes on GNU/Linux - here it's glibc saying "I just caught you doing something really dumb, time to die." Both smell like a memory management problem in Unity to me, and I wouldn't be at all surprised if it's all the same bug. My stack traces appear to point the finger at mono, or the Unity/mono interface. Others have similar ideas but without help from the Unity devs and/or some source code and debug builds to play with, I'm as stumped as you.

Count me among them, though I wouldn't say "Hate" - more "Meh, this is pretty uninspiring." I was slightly disappointed, though not at all surprised, that 1.1 hasn't improved this. Stock contracts are just based on a fundamentally flawed concept IMO. I believe it was Regex who recently said something like: "Squad has saddled themselves with a side-quest system." I agree, and I don't find it particularly fun. It feels too much like work, and the goals aren't remotely interesting. Done one part test, done them all. Plant another flag somewhere on the Mun... Why? Some people seem to enjoy the grind, but for me career mode is exceedingly boring and repetitive without a heap of career mods and contract packs. Most of them are so much better than stock, it can actually make career a fairly enjoyable experience. Nightingales Strategia, for example, gives a sense of long-term planning and progression sorely missing in the base game, and there are several others that have a similar effect - bringing some management to managing a space program. As for the OP... I can't really make heads nor tails of it, so: ¯\_(ツ)_/¯

Intermittent crashes here too. I do believe I have said my words on this. But I'll say it one more time for completeness: Progress fixing this: nil. Bug reports (with stack traces etc.): no comment from devs, besides the standard "Unity problem". Game still crashing randomly. Not impressed. To quote a certain staff member: "It's on the tracker already but I think this one may need to be posted to the Unity forums as it seems to be an issue in the libmono bundled with Unity." Seriously? since when is punting bug reports upstream the players job? We bought Kerbal Space Program, not Unity Tech Demo.

You think that's mean, I have been known to spin-stabilise early career lifters all the way up Since one doesn't get usefull probe cores until later on... Vomit Rocket it is.

FWIW, the patcher borks Linux installs too (see startup error further up the thread). The patcher itself (and rsync) produce no log errors and the process completes "successfully". I don't know exactly what lives at rsync://kerbalspaceprogram.com:873/kerbalsp.production/KSP_linux/, but I'm fairly certain it's not a complete 1.1.2. This worked fine for 1.1.0 -> 1.1.1, perhaps somebody forgot to update the sync server... A more minor issue is that it also removes the executable flag from KSP.x86_64. Did anyone actually test this thing before letting it out into the wild again? Sure doesn't look that way to me. For those with slow connections (mine is slow-ish too), I feel your pain. That said, manually rsyncing an unpacked 1.1.1 -> 1.1.2 (which works fine) pulls about 400MB, so less savings with this patch than the last one. Still 50% smaller download though. Better could probably be achieved with binary deltas, though that's more work to set up than rsync. Rsync is easy, come on Squad, if I can rsync patch 1.1.1 to 1.1.2 without breaking things so can you.

Yeah, that. This editor is incredibly frustrating, and it doesn't work at all well on mobile. But hey, it's been said a bunch of times by various people and nothing has changed, so...

Oops, guess I shoud have read back up the thread. Apologies for the noise.

Sounds about right to me, to the best of my knowledge. (C = some, mono = sweet FA, Unity = Nil) I know what the error means in the context of native C/C++ (pretty much exactly what it says, glibc thinks somebody has freed the same block of memory twice, potentially corrupting the heap) If this occurs, by default glibc will abort and output a stack trace on STDERR. This behaviour can be turned off, but it's not a particularly good idea, for fairly obvious reasons. If your theory is correct, and the breakdown is in one of Unitys own mystery-meat methods, this may well be impossible to pin down without the Unity sources. The intermittent bit I would expect for this kind of error, as when a double free occurs, the behaviour is undefined. If that pointer is NULL at the time, we're all good. If it's not, chaos ensues. This could also be a thread-safety problem *shudder* which would be even more fun to find. Either way, I'm guessing (I don't read Windows stack traces ) it's the root cause of crashes on all platforms. Use of Electric Fence or Valgrind might be enlightening, but that will require a debug build (of the Unity player too, not just mono), and to be realistic, a copy of the source code to make sense of it. I have neither, hence asking if someone with better skills and tools is looking into this. Indeed, I already have (several copies of) that repo. I have been mucking about with it, but my foo is limited as is my time, so finding this (if it's even in mono), without source or a debug build of the rest of Unity is not really going to be a thing for me. I'll probably waste time on it anyway though.

We've been waiting nearly a year now for the non-steam patcher to be fixed. Squad have necroed it recently (though it appears no updates to the code have taken place), so feel free to try it out (hint: "update" button in the launcher)... But make a backup first, as it has botched two 1.1.1 -> 1.1.2 updates for me. Personally, I've just shifted from waiting for it to be fixed to waiting for it to be fixed properly, and tested. While mine is not quite that slow, I hear you on the needless waste of bandwidth. --- ed. I just ran the patcher against my working copy of 1.1.2... results in a corrupted install and game fails to start. @SQUAD: Please fix the patcher. Rsync reports all files synchronised succesfully (and it shouldn't have synced any files, this is already 1.1.2) so I suspect that whatever is is synchronising with is not what it seems. I will report a proper bug, with logs, file checksums etc. on the condition that I get a reply to this. I am getting tired of bugs.

Ditto, though I'm not sure if this is intended behaviour or not. Appears to persist through building upgrades too The actual strategy limit is always the stated maximum -1. Nothing suspicious in the logs, but I can grab one if it would help.

Ahh, the dreaded "double free or corruption" crash. (look at the very top of your log) I get these too, though I can't reproduce it reliably. The only word I have heard from Squad so far is this: You have a craft that causes it reliably, and you say it always happens at the same altitude... this may be useful information to take to the bug tracker. From the above quote it sounds very much like Squad doesn't intend to do anything about it though. I wish I could help here, but I'm looking for an answer too.

I have been getting these too. If I go to the effort of providing a bunch of stack traces from a mono built with debugging symbols and complete gdb output, would these be any help? Is anyone doing any real investigation into this issue? The hotfixes have changed nothing regarding this crash.

So you missed the bit where I mentioned that the launcher does this too? - it's a 2D window with an image, some text and what, 4 buttons? How is this any more complicated than a "Desktop app"? Drawing a 2D window like this in X11 is not complicated, I can provide example code (C) if required. Yes, I do realise that he launcher is Unity too. And no, that's not a good excuse. Nowhere did I suggest that I have more than one monitor, because I do not. It does this with a single display too. Strike xinerama off the list. I have run dual head in the past... guess what? no problems like this encountered. Aside, care to enlighten me about these "quirks" in xrandr? My code works just fine and I've never had any problem with xrandr, so I'm not sure what you're talking about. If this is really so difficult, why have I not encountered, in over ~15 years with X, a single native application that behaves like this? Honestly, I still can't figure out how to draw a window as broken as what I see from Unity (other than explicitly coding this behaviour) - even when rendering the contents in OpenGL. I don't have the Unity sources, so I'm not going to look too far into what it's doing. As far as I can tell, there's no real explanation other than "it's doing it wrong". Note that in my book loading a full 3D render pipeline to draw a 2D window like the launcher is also "doing it wrong". ---- Unity does sell source code licences. If they won't fix this rubbish, Squad needs to go buy one and fix it themselves, these endless Unity bugs are crippling KSP.

Stability, stutter-free performance & wheels that work properly. For everything else there are perfectly good mods.

Sure, I'd love to use windowed-mode... Assuming, that is, that it creates a window of a reasonable, predictable size. If "windowed" means a non-resizeable window at some insane geometry like 4000x1 or 10x10, I guess I'll have to run it in full-screen. Seriously guys, placing windows on the screen correctly has been a thing for some 20 years, it boggles the mind that Unity can fail so spectacularly at this simple task. On that note, what exactly are we supposed to do with the "Launcher"? It suffers the same issues and has no fullscreen mode... So?

I wasn't being particularly serious with this one, very much tongue-in-cheek. I don't expect much can be saved when it crashes with "Error in `./KSP.x86_64': double free or corruption (out)" and a native stack-trace either... But hey, mods fix everything else, right?

It sure is. Not the Unity editor (used by Squad to create KSP, but not included in the DL), but the Unity3D player - without this there is no game. It's in disguise of course, and goes by the name "KSP.x86_64". To put it another way, Unity is the game. It's the only part that runs natively on your OS, KSP itself is a bunch of assets and managed code that is loaded by, and runs inside Unity. This is the easy way to make a cross-platform game, because the same managed code can run on any operating system unity can, without modification. Unfortunately it's also the easy way to leave your game at the mercy of bugs in code you didn't write, as we have seen here today.

While this sounds good - in theory - I am still encountering too many wheel-related bugs, crashes and random "WTF just exploded" glitches in 1.1 to play without quicksave/load. I would like to play iron-man mode, but there is still far too much kraken bait in this game IME. I do impose my own limits on save-scumming, but I will not lose kerbals to bugs. Catching Alt-F4 won't stop me just kiling the process if i wanted to anyway. OTOH, if you can get the game to save before it crashes, that would be excellent.

Yeah, that. If I recall correctly, one of the points I made in my most recent "1.1 is still a freaking beta" rants was... All these bandaid wheel fixes (that don't address the underlying problem) have caused other issues. I rest my case. And.. left is the direction my landers spin with SAS off too. On a slightly different note, I just had a ~30T aircraft fired ~500m into the air by a gear malf Apparently taxiing on a slope is kraken bait now. As is touching any surface that's not dead-level. Or touching landing legs with anything. Or putting landing legs on a craft at all, for that matter. This is getting ridiculous, the more I play try to play 1.1.<whatever broken patch we're running now>, the more I come to realise just how bung it is, and how half-arsed the Squads last minute "fixes" really are. --- Ya know what the best bit is? Since you mentioned it, I checked... grounded craft still drift. It's so slow now that you have to be pretty patient to see it, but it's there. "Fixed" indeed. I keep coming back to this game, thinking "maybe it's mods" - nope "maybe it's my craft" - nope "maybe if I just muck with it a little longer"... Screw it. Bravo Squad. Whatcha got planned for the next "hot fix"? There must be something left to break.

An excellent question. I'm pretty sure I have been seeing the same thing, but so far I can't reproduce it accurately enough for a decent bug report... About all I can say is that if it does exist (and it's not mods causing it), it only does so on craft with landing struts or wheels. I vaguely recall some mention of Squad applying a force to counter a phantom force from the wheels / struts and make them stay still on the surface... but TBH I can't recall where, so I may have imagined it. If this was actually the case it would explain much. Anyone else seeing this?

Fair enough, no pressure. Just letting you know I really like that feature. (and stock SAS appears to be extra wonky in 1.1 , or have I just become acustomed to using PA?)

Thank you, this is most certainly on my "critical mods" list, the game would not be the same without it. Guess I don't realise how much I relied on the SAS tuner until now You are bringing it back at some point, right? I have only one (that I have noticed)... bank angle appears to be reversed. Negative bank angle in the "Target Bank" field (or via yaw key input) results in positive bank applied, and vice-versa.

ROFL, people have been asking for that for as long as CKAN has existed. The answer is, apparently, a resounding no. From the CLI: ckan.exe upgrade <mod identifier>=<version> will force the issue. Get version and mod identifier from the gui (look at bottom of "metadata" panel for id) or by grepping through CKAN/registry.json. I don't know where this attitude regarding user-overrides comes from, but it's a royal pain in the proverbial. So much so that I'm still doing manual installs.