Jump to content

Crashes Post 1.1.X Simple Question for the affected ones


AlamoVampire

Recommended Posts

  On 5/7/2016 at 9:58 AM, STS Fallacy said:

Now seriously: That dll was the reason of all three windows CTDs I had. Something fishy going on in there.

Expand  

If by "that dll" you mean ntdll.dll: Argggggh. One more time: ntdll.dll is a core part of the Windows OS. It's not causing anything. If there was something wrong with ntdll.dll, do you not think some of the millions of other windows applications out there would have revealed it by now?

I'm sorry if I come across as being harsh, but wild speculation based on a line in a stack trace you don't seem to know how to read is not helping.

  On 5/7/2016 at 9:58 AM, STS Fallacy said:

Played KSP 1.1.2 for about 30 hours on my mac. One CTD.

Expand  

On the other hand, confirming that KSP crashes randomly on mac too is mildly helpful.
Note that there is no ntdll.dll on Mac or Linux, yet the game still crashes. The apparently random nature of this issue would explain the variation in frequency, but the fact is: It shouldn't crash at all.

----

And earlier:

  On 5/7/2016 at 5:05 AM, Bloodbunny said:

I note that some folks are having crash problems with stock, and others are running 20+ mods without issue. I'm willing to bet that the stability is based on PC performance, beefy top end gaming PCs can run a metric ton of mods with few issues, mid range PCs are crashing with mods, and potatoes are crashing with stock.

Expand  

Are you claiming my PC is a "potato"? While no longer top-of-the-line, I can assure you it exceeds the minimum requirements by a hefty margin. I see stock crashes. Prior to 1.1 I saw zero crashes - even when running 100+ mods and using 10GB of RAM.

For the record: Intel i7-3820, 16GB quad-channel DDR3, Nvidia GTX680 (x2). If that's a "potato" I assume you have a Cray on your desk, no?

Edited by steve_v
Link to comment
Share on other sites

  On 5/7/2016 at 10:45 AM, steve_v said:

If by "that dll" you mean ntdll.dll: Argggggh. One more time: ntdll.dll is a core part of the Windows OS. It's not causing anything. If there was something wrong with ntdll.dll, do you not think some of the millions of other windows applications out there would have revealed it by now?

I'm sorry if I come across as being harsh, but wild speculation based on a line in a stack trace you don't seem to know how to read is not helping.

Expand  

Core part of windows or not, some interaction with that dll (or its subprocesses) has resulted in a crash. In my opinion, it wouldn't be the first time that lousy programming of the system itself has messed up a program.

Edited by STS Fallacy
Link to comment
Share on other sites

  On 5/4/2016 at 2:32 PM, Curveball Anders said:

C(rud) Cleaner https://en.wikipedia.org/wiki/CCleaner is a useful tool to find, list and possibly deactivate stuff that might cause issues.

It's a little bit more user friendly than msconfig, but note that it can be as dangerous if not handled with care.

Expand  

CCleaner is good but it is like having Roto Rooter over for your pipes. Not really a good idea to keep around all the time. I find it best to install it when you are having issues, and when it is done to just remove it. Save it for extreme cases and not as a mainstay.

Link to comment
Share on other sites

  On 5/7/2016 at 8:55 PM, STS Fallacy said:

Core part of windows or not, some interaction with that dll (or its subprocesses) has resulted in a crash. In my opinion, it wouldn't be the first time that lousy programming of the system itself has messed up a program.

Expand  

-redacted for reasons it was a non-contributory statement-

Edited by samstarman5
Link to comment
Share on other sites

  On 5/7/2016 at 8:10 AM, steve_v said:

a: I don't have NovaPunch installed.

b: This also occurs in the stock game.

c: If part mods (or any mods for that matter) can cause native memory-managemant faults, there's something horribly wrong with the CLI runtime. Isolating managed code from this kind of thing is the whole point in having such a runtime.

It's not mods causing this. Mods might be exacerbating it, but if that's the case then they are simply revealing a flaw in the underlying system.

Expand  

Exactly, I didn't mean Novapunch was causing it specifically, it was just serving as the proverbial straw that breaks the camel's back in @Alamovampire's case. Adding mods reveal a fundamental problem with Unity 5, and I hypothesize that it becomes apparent with fewer mods, based on an individual PC's performance, which is why some people are getting the crash with the stock game.

 

Your PC is comparable to mine, mid range, no offense intended. That is important because if you are getting stock crashes in the VAB then it isn't related to overall PC performance, but rather just a flaw with Unity; it shouldn't be crashing AT ALL. (Indeed it never crashed on me in the VAB prior to 1.1 unless it went over the 32-bit RAM limit, or I was using the 64 bit hack.) With 1,1 and later, I can get a VAB crash in 2 minutes, or 20 minutes. I haven't had one while running stock, BUT I haven't tried running stock for more than 30 minutes at a time.

Edited by Bloodbunny
Link to comment
Share on other sites

  On 5/7/2016 at 10:51 PM, samstarman5 said:

CCleaner is good but it is like having Roto Rooter over for your pipes. Not really a good idea to keep around all the time. I find it best to install it when you are having issues, and when it is done to just remove it. Save it for extreme cases and not as a mainstay.

Expand  

I don't let it run in the background (of course).

I use it at regular intervals to clean out crud and keep an eye on installed software (and plugins)

 

Link to comment
Share on other sites

  On 5/7/2016 at 8:55 PM, STS Fallacy said:

Core part of windows or not, some interaction with that dll (or its subprocesses) has resulted in a crash. In my opinion, it wouldn't be the first time that lousy programming of the system itself has messed up a program.

Expand  

Excuse me Sir but that's completely unrelated to the issue at hand.

KSP interacts with Unity (and some plugins I think).

Unity interacts with Mono (dotnet) and some other bits and bobs.

Mono and other bits and bobs interact with the core apis and drivers of the three OS:es that are supported.

Without a way to reproduce a crash there's more or less no way to find out what's causing the problem and solve it by changing the broken code (or code around a bug in some other code).

If someone has a way to force/create a crash then the logs can be compared with similar system to narrow down the issue(s) at hand.

I was away from my rig over the weekend and only spend some hours toying with on my underpowered win7-32 4G (as in 3.5) ram laptoy, aka typewriter. I used a clone from my main rig so I kept the part count down but I didn't have a single crash.

But since there are several users who suffer constant crashes on similar systems, even totally stock, there's has to be something in some systems that doesn't play nice (or aren't played nice) with KSP (and/or Unity5).

The only way forward is to find that trigger, or module, or behaviour, so Squad can correct it, or code around it.

Link to comment
Share on other sites

Okay so I might have something. This is actually done in 1.1.0 and not 1.1.2 so further testing is required to be sure this is actually a valid issue (I run ksp store install so that's not exactly a quick and easily automated process). Allegedly the crashes though persist through the hotfixes.

Kopernicus might actually improve the reliability of the crashing. This is the last bit of the output log from a crash that happened when I hit "return to space center" from an active vessel after less than an hour of gameplay. I'm running OPM and I noticed some kopernicus debug lines in there with the stack trace. Not sure if thats related or if the log write order just got a bit messed up at the end there or not. Either way, I'm passing this off to someone a bit more versed in this debugging than I.

  Reveal hidden contents

If the kopernicus plugin is in fact increasing the frequency of these crashes, then we might be able to improve the odds of getting this properly diagnosed. The "return to space center" crash has definitely happened for me more than once but correlation does not always equal causation. Its still a random crash, not doing it every time, but a shred of predictability can shed a lot of light on this.

Link to comment
Share on other sites

  On 5/8/2016 at 8:36 PM, Curveball Anders said:

I don't let it run in the background (of course).

I use it at regular intervals to clean out crud and keep an eye on installed software (and plugins)

 

Expand  

Better to actually uninstall it. Not everything you don't let run in the background always listens to you, especially after you run it and then close it.  Chkdsk and your antivirus/antimalware can keep an eye on things regularly, and save CCleaner for like every 6 months.

Link to comment
Share on other sites

  On 5/7/2016 at 8:55 PM, STS Fallacy said:

Core part of windows or not, some interaction with that dll (or its subprocesses) has resulted in a crash. In my opinion, it wouldn't be the first time that lousy programming of the system itself has messed up a program.

Expand  

The "crash" in ntdll.dll isn't a case of the OS doing anything bad.  What is happening is that ntdll.dll is raising a structured exception because it has been called incorrectly by the program and the default (and, arguably, the most sensible) way of handling such an exception is to terminate the process.

It is trivially easy to write a program in C/C++ (or any other compiled language that lets you call OS functions directly) that will fail with exactly that stack trace.  The underlying cause is probably the same as the "double free or corruption" error seen from glibc, namely that an invalid pointer is passed to a function that releases memory.  Whether the pointer has been previously freed, its value has been corrupted or the data it points to has been corrupted remains to be seen but any of these could easily cause both of these sorts of problems.

Also, on the subject of how the game uses memory, it isn't as simple as Unity asking the OS for memory and giving it to Mono and then KSP code uses that.  Unity almost certainly uses a different API to allocate the memory it gives to Mono than what it uses to allocate memory for other things it needs to do.  Most normal memory allocation in C/C++ is done using either malloc/free in the case of C and new/delete in the case of C++.  These APIs are actually implemented by the C runtime (e.g. glibc) or the C++ runtime and they call the functions in ntdll.dll (or the Linux/OSX equivalents).  In the case of the memory given to Mono, I suspect that Unity calls directly to the OS APIs rather than going though the C/C++ library.

My take on this whole "random crash" issue is that there is almost certainly an underlying bug in Unity, most likely caused by a multi-threading issue, because these crashes always seem to occur at times when Unity is likely to be doing more work in background threads.  Multi-threading is hard and Unity does quite a lot of it.  If data is shared between threads but is not correctly protected from simultaneous access then it is quite easy to end up with this sort of "random" crash.  Sometimes, it requires one thread to be at a particular instruction in the code when another thread accesses the data for there to be a problem.  It can even require one thread to be suspended at a particular instruction to allow some other thread to run, e.g. if you have a pointer that is shared between two threads where each thread is careful to null check before using the pointer then you might imagine it would be safe for one thread to release the pointer and then set it to null but, if the other thread has just executed its null check and then gets pre-empted before using the pointer then the first thread could release the pointer and set it to null but the other thread would go ahead and use the pointer when it gets resumed.  If nothing else happened in the first thread then this might not cause any obvious problem, e.g. the second thread could just be using the memory as a buffer to store data in and would just be writing the data into memory that has been freed but, if the first thread (or any other thread) happens to do any memory allocation before the second thread is resumed then the memory could be reused for another purpose and then have its contents corrupted by the second thread.  The second thread could even do a memory allocation and get given the same pointer for the new allocation as it has for its buffer.

Link to comment
Share on other sites

  On 5/10/2016 at 12:06 PM, Padishar said:

My take on this whole "random crash" issue is that there is almost certainly an underlying bug in Unity, most likely caused by a multi-threading issue, because these crashes always seem to occur at times when Unity is likely to be doing more work in background threads.

Expand  

Yup, that's my guess as well.

The randomness hints at some form of race condition between two or more threads.

Link to comment
Share on other sites

I've been hit too, it seems.

Only when scrapping parts in the VAB/SPH. Lot's of mods.

Haven't had any problems with Stock

  On 5/10/2016 at 2:05 PM, Curveball Anders said:

The randomness hints at some form of race condition between two or more threads.

Expand  

Is KSP x32 single threaded? Or is Unity still doing multi-thread stuff in the background?

If its the former, that would be an easy way to test if its a threading issue.

Link to comment
Share on other sites

  On 5/12/2016 at 11:33 PM, CaribouGone said:

Is KSP x32 single threaded? Or is Unity still doing multi-thread stuff in the background?

Expand  

No, the 32 bit version is also multi-threaded, Unity does quite a lot of stuff in the background and, in the case of the VAB, it isn't at all obvious why it does so much...

Link to comment
Share on other sites

  On 5/12/2016 at 11:37 PM, Padishar said:

No, the 32 bit version is also multi-threaded, Unity does quite a lot of stuff in the background and, in the case of the VAB, it isn't at all obvious why it does so much...

Expand  

After a quick peek in the process tree (running both 64 and 32) it's clear that Unity does quite a bit of multi threading. The most obvious being music and other sounds, but also other stuff (rendering & PhysX?).

But I was only noting that those seemingly random crashes, where several seems to be due to memory corruption, raises a suspicion of threads getting out of sync and messing up memory management

Link to comment
Share on other sites

  On 5/14/2016 at 3:16 AM, cyberpawn said:

i think squad focus on 64bit system now.. and 32bit is abandoned..

Expand  

Why would you say that when most of the reports of random crashes are from people running the 64 bit version?

Please don't post deliberately inflammatory statements with little basis in fact...

Link to comment
Share on other sites

  On 5/14/2016 at 9:21 AM, Padishar said:

Why would you say that when most of the reports of random crashes are from people running the 64 bit version?

Please don't post deliberately inflammatory statements with little basis in fact...

Expand  

well.. most ksp player is 64bit users and some 32bit users like me.. in my view.. they update unity 4 to 5 because most request it from 64bit users..

i'm  not confident to what i'm saying.. but i'm waiting for next patch.. if they fix for 64bit users but still crashing for some 32bit users.. they focus on big system..

Link to comment
Share on other sites

I started playing KSP on a pretty old system. Like a GTX 220 or something, old processor, 32 bit system, 4 GB ram. I had to turn things down pretty far to get the game to work ok, & I had crashes like maybe once every 15 min or so.

A few days ago I finally got my new system in. Its a i7 6700k, 16 GB ram, with a GTX 970. Of course it runs KSP flawlessly capped at 120 FPS with everything cranked all the way up. I'm now playing the 64 bit version also, but it still randomly crashes. :( But now its a lot less often than before. Maybe once every couple of hours or so. Not sure whats causing it at this point. Its definitely not because my system cant handle the game! :wink:

Link to comment
Share on other sites

  On 5/14/2016 at 7:17 PM, Waxing_Kibbous said:

Do these crashes show up in the Windows crash logger? There is a pretty nice stock Win program, Event Viewer, that can give you quite a bit of info.

Expand  

In the only crash I've had the windows logger just stated 'terminated by ntdll', as in memory mismanagement.

A peek at the dump with windebug just added that it was a call from mono caused by a thread awake call.

In other words, nothing new to be learned without a debug build.

Link to comment
Share on other sites

  On 5/14/2016 at 1:32 PM, RX2000 said:

I started playing KSP on a pretty old system. Like a GTX 220 or something, old processor, 32 bit system, 4 GB ram. I had to turn things down pretty far to get the game to work ok, & I had crashes like maybe once every 15 min or so.

A few days ago I finally got my new system in. Its a i7 6700k, 16 GB ram, with a GTX 970. Of course it runs KSP flawlessly capped at 120 FPS with everything cranked all the way up. I'm now playing the 64 bit version also, but it still randomly crashes. :( But now its a lot less often than before. Maybe once every couple of hours or so. Not sure whats causing it at this point. Its definitely not because my system cant handle the game! :wink:

Expand  

I kinda imagine ksp like balloon, it gets bigger when you play, bigger with time, a lot bigger if you play with mods, then it goes boom! start again.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...