BUST: 1.1.X Crashes (Your Help Requested!)

[MircoMars]

On 4.6.2016 at 0:25 PM, AlamoVampire said:

@Claw new data point for you! Running as Admin again [...]

I just tried running ksp_x64.exe as admin and it crashed on me in VAB while placing a pair of radial chutes... so this is not the solution, at least not for me. 

I run a modded install (see spoilers below) and crash regularly in VAB or while staging. I looked at the ksp.log from that last CTD and it's spammed with:

[LOG 13:44:59.912] RemoteTech: ModuleRTDataTransmitter::OnSave
[LOG 13:44:59.913] RemoteTech: ModuleRTDataTransmitter::OnSave
[LOG 13:44:59.914] RemoteTech: ModuleRTDataTransmitter::OnSave
[LOG 13:44:59.916] RemoteTech: ModuleRTDataTransmitter::OnSave

Will do some testing with a fresh stock install tonight...

Spoiler

Specs:

Spoiler

Kerbal Space Program - 1.1.2.1260 (WindowsPlayer)

OS: Windows 7 Service Pack 1 (6.1.7601) 64bit
CPU: AMD Phenom(tm) 8400 Triple-Core Processor (3)
RAM: 4096
GPU: AMD RADEON HD 6450 (1012MB)
SM: 30 (Direct3D 9.0c [aticfx64.dll 8.17.10.1404])
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8
 

settings.cfg

Spoiler

SETTINGS_FILE_VERSION = 1.1.0
TUTORIALS_EDITOR_ENABLE = False
TUTORIALS_FLIGHT_ENABLE = False
VAB_USE_CLICK_PLACE = True
VAB_USE_ANGLE_SNAP = True
VAB_ANGLE_SNAP_INCLUDE_VERTICAL = False
VAB_FINE_OFFSET_THRESHOLD = 0.2
VAB_CAMERA_ORBIT_SENS = 0.04
VAB_CAMERA_ZOOM_SENS = 0.1
FLT_CAMERA_ORBIT_SENS = 0.04
FLT_CAMERA_ZOOM_SENS = 0.5
FLT_CAMERA_WOBBLE = 0.1
FLT_CAMERA_CHASE_SHARPNESS = 1.5
FLT_CAMERA_CHASE_USEVELOCITYVECTOR = True
FLT_VESSEL_LABELS = True
SPACENAV_CAMERA_SENS_ROT = 30
SPACENAV_CAMERA_SENS_LIN = 20
SPACENAV_CAMERA_SHARPNESS_LIN = 8
SPACENAV_CAMERA_SHARPNESS_ROT = 10
CAMERA_DOUBLECLICK_MOUSELOOK = False
DOUBLECLICK_MOUSESPEED = 0.2
IVA_RETAIN_CONTROL_POINT = False
CAMERA_FX_EXTERNAL = 0.140625
CAMERA_FX_INTERNAL = 1
SIMULATE_IN_BACKGROUND = False
PHYSICS_FRAME_DT_LIMIT = 0.04
MAX_VESSELS_BUDGET = 250
DECLUTTER_KSC = True
CONIC_PATCH_DRAW_MODE = 3
CONIC_PATCH_LIMIT = 3
ORBIT_FADE_STRENGTH = 1
ORBIT_FADE_DIRECTION_INV = False
ORBIT_WARP_DOWN_AT_SOI = True
SHOW_PWARP_WARNING = False
EVA_ROTATE_ON_MOVE = True
SPACENAV_FLIGHT_SENS_ROT = 5
SPACENAV_FLIGHT_SENS_LIN = 1
KERBIN_TIME = True
SHOW_VERSION_WATERMARK = False
CALL_HOME_PROMPT = False
DONT_SEND_IP = True
SEND_PROGRESS_DATA = False
CHECK_FOR_UPDATES = True
VERBOSE_DEBUG_LOG = False
SHOW_CONSOLE_ON_ERROR = False
AUTOSAVE_INTERVAL = 300
AUTOSAVE_SHORT_INTERVAL = 30
SAVE_BACKUPS = 5
SHOW_SPACE_CENTER_CREW = False
WHEEL_CLIP_OFFSET = 0
WHEEL_CLIP_RANGE = 1
WHEEL_CLIP_MULTIPLIER = 1.05
WHEEL_SUBSTEPS_ACTIVE = 8
WHEEL_SUBSTEPS_INACTIVE = 4
UI_SCALE = 0.9
UI_OPACITY = 0.5
UIELEMENTSCALINGENABLED = True
UI_SCALE_TIME = 1
UI_SCALE_ALTIMETER = 1
UI_SCALE_MAPOPTIONS = 1
UI_SCALE_APPS = 1
UI_SCALE_STAGINGSTACK = 1
UI_SCALE_MODE = 1
UI_SCALE_NAVBALL = 1
UI_SCALE_CREW = 1
UI_POS_NAVBALL = 0
TEMPERATURE_GAUGES_MODE = 3
MASTER_VOLUME = 0.1006098
SHIP_VOLUME = 0.1006098
AMBIENCE_VOLUME = 0.1006098
MUSIC_VOLUME = 0
UI_VOLUME = 0.1006098
VOICE_VOLUME = 0.05487805
SOUND_NORMALIZER_ENABLED = False
SOUND_NORMALIZER_THRESHOLD = 1
SOUND_NORMALIZER_RESPONSIVENESS = 16
SOUND_NORMALIZER_SKIPSAMPLES = 0
SCREEN_RESOLUTION_WIDTH = 1280
SCREEN_RESOLUTION_HEIGHT = 720
FULLSCREEN = True
QUALITY_PRESET = 1
ANTI_ALIASING = 0
TEXTURE_QUALITY = 2
SYNC_VBL = 1
LIGHT_QUALITY = 8
SHADOWS_QUALITY = 4
FRAMERATE_LIMIT = 120
PLANET_SCATTER = False
PLANET_SCATTER_FACTOR = 0.5
WATERLEVEL_BASE_OFFSET = 1.5
WATERLEVEL_MAXLEVEL_MULT = 0.1
UNSUPPORTED_LEGACY_SHADER_TERRAIN = False
AERO_FX_QUALITY = 2
SURFACE_FX = False
INFLIGHT_HIGHLIGHT = True
FALLBACK_UNDERWATER_MODE = 2
EDGE_HIGHLIGHTING_PPFX = False
SCREENSHOT_SUPERSIZE = 0
ALLOW_NEGATIVE_FUNDS = False
ALLOW_NEGATIVE_SCIENCE = False
SHOW_DEADLINES_AS_DATES = False
DEFAULT_KERBAL_RESPAWN_TIMER = 7200
INPUT_KEYBOARD_SENSIVITITY = 2
dontShowLauncher = False
TRACKIR_ENABLED = False
FEMALE_EYE_OFFSET_X = 0
FEMALE_EYE_OFFSET_Y = 0.009083331
FEMALE_EYE_OFFSET_Z = 0.03378779
FEMALE_EYE_OFFSET_SCALE = 2.03
FI_LOG_TEMP_ERROR = False
FI_LOG_OVERTEMP = False
LOG_INSTANT_FLUSH = False
CAN_ALWAYS_QUICKSAVE = False

GameData

Spoiler

000_Toolbar, CommunityResourcePack, ContractConfigurator, ContractsPacks, DMagicOrbitalScience, DMagicUtilities, KAS, KerbalConstructionTime, KerbalEngineer, KerbalJointReinforcement, KIS, KRASH, MechJeb2, RemoteTech, SCANsat, Squad (duh), StageRecovery, TriggerTech, UniversalStorage

I know, lots of mods. This install ain't for debugging...

 

 

 

[Waxing_Kibbous]

Just had a crash on Linux, on the runway, a similar thing has happened on the grasslands. The cast shadows get wavy, as in not flickering, but a very fast wave motion. When I click to recover I get a crash. Using the stock bugfix mod and VAB lighting fix. This interesting tidbit is in the Player.log:

Native stacktrace:

	/home/foo/Desktop/KSP_linux (2)/KSP_Data/Mono/x86_64/libmono.so(+0x91772) [0x7f5cd0522772]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0) [0x7f5cd366a3d0]
	/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7f5cd1e3e418]
	/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f5cd1e4001a]
	/lib/x86_64-linux-gnu/libc.so.6(+0x7772a) [0x7f5cd1e8072a]
	/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a) [0x7f5cd1e88f4a]
	/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c) [0x7f5cd1e8cabc]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x5a5558]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x5813fc]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x578744]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x47416a]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x71f7fa]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x723e1a]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x73530d]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x72f83b]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x7301a2]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x72b2a3]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x461f1b]
	/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f5cd1e29830]
	/home/foo/Desktop/KSP_linux (2)/KSP.x86_64() [0x46b4ed]

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No threads.

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Ubuntu 16.04 64 bit, GTX950 using Nvidia drivers.

Edit: this is driving me nuts but I can't make it happen again reliably. The shadows are still wobbly, even on Val in the opening menu, but I can't get a consistent crash. Will keep trying.

Edited June 5, 2016 by Waxing_Kibbous

[AlamoVampire]

@MircoMars Interesting. I run modded too. Mechjeb, proc fairings, novapunch (np is still way outdated but since i crashed clean after slashing and burning in april i know np isnt hurting me..yet) and have crashed with run as admin but less often. 

Why our results differ is beyond me, but its an interesting data point for @Claw tho i think

[Jarin]

Where's the best place to post info related to the "crash on staging" rather than "crash on deleting part in VAB"?

[Claw]

Running as admin or with DEP off is kinda odd, but good to know. Those sorts of things still make me think there's some odd happenings with threads in the background.

As for the "crash on staging," depends on what your log files say. If they have similar indications as what have been posted here (which is basically no errors, and just a Crash!), then it might be something to investigate here.. Does it crash right at the stage event, or sometime after?

[Jarin]

Immediately on stage event. Nothing that I can see in the log; no crash-log generated.

Windows event log captures this;

Faulting application name: KSP_x64.exe, version: 5.2.4.2391, time stamp: 0x566b7225
Faulting module name: ntdll.dll, version: 10.0.10586.306, time stamp: 0x571af2eb
Exception code: 0xc0000005
Fault offset: 0x000000000002e909
Faulting process id: 0x3830
Faulting application start time: 0x01d1bfb0f73e3771
Faulting application path: F:\SteamLibrary\steamapps\common\Kerbal Space Program\KSP_x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 974fd018-9950-415c-bec1-c30695c51ca1
Faulting package full name: 
Faulting package-relative application ID: 

Which... I think is an NVIDIA driver dll? I've updated/reinstalled the video drivers but that didn't seem to help.

Edited June 6, 2016 by Jarin

[MircoMars]

I did a short test in the modded install (see my earlier post) and set my cpu affinity to only one core. It was slow, but stable. I will go on testing this in a stock install tonight. 

perhaps some of you could try this, too. either set affinity after starting ksp via process-tab in taskmanager or use this description to edit the shotcut: http://www.eightforums.com/tutorials/40339-cpu-affinity-shortcut-program-create-windows.html (I have no affiliation to this site, I just don't want to explain the binary stuff)

[kiwi1960]

I get the crash at various times, its more than annoying, it makes the game unplayable and I'd rather not waste my time on it till its fixed.

Having said that, that doesn't mean I'm not going to add my 10 cents worth IF what I say can help, and then, I don't know because when it crashes, there is no log.

So, here goes. Forgive me if I do not know the techno speak or if I sound confusing, these are my observations, take them or leave them, you decide.

The crashes happen, as far as I can tell, because the parts you are using, modded or not, gets "lost" by the code, maybe because the 32 bit limit is gone now, so the program is having a hard time keeping track of it all, I mean, less than 4 gigs, it was fine, but more than that, it gets confused... especially if there is a leak somewhere. So when you access a part, it loses the data that is in memory and crashes back to the desktop. So my guess is... and its only a guess... the garbage cleaning process is deleting things it shouldn't.

 

[Padishar]

On 6/6/2016 at 3:19 PM, Jarin said:

Which... I think is an NVIDIA driver dll? I've updated/reinstalled the video drivers but that didn't seem to help.

No, ntdll.dll is a fundamental part of the Windows operating system.  This crash basically means that the program passed a dodgy pointer (i.e. a memory address which doesn't actually have real memory behind it or an address the program doesn't have permission to access in the way it is trying to) to an operating system function (probably a memory allocation/deallocation function) and the 0xC0000005 exception code is how the operating system tells the program it has done something very bad.  It is not (usually) sensible for a program to continue running after this sort of exception as it generally means that some of the program's data is in a very dodgy state and it is safer that the program just dies than, e.g. trying to write out a save file and corrupting your save.

11 hours ago, MircoMars said:

I did a short test in the modded install (see my earlier post) and set my cpu affinity to only one core. It was slow, but stable.

This is a promising line of investigation as the problem is very likely to be caused (or, at least, exacerbated) by multi-threaded code.  The VAB/SPH actually do more multi-threading than most other parts of the game.  If the crashes really don't occur when set to a single core then this could be very useful information for the devs to know...

8 hours ago, kiwi1960 said:

I don't know because when it crashes, there is no log.

There is always a log.  There may not be a specific "crash" log but the output_log.txt (or player.log on Mac and linux) file is always recreated every time you start the game.

8 hours ago, kiwi1960 said:

The crashes happen, as far as I can tell, because the parts you are using, modded or not, gets "lost" by the code, maybe because the 32 bit limit is gone now, so the program is having a hard time keeping track of it all, I mean, less than 4 gigs, it was fine, but more than that, it gets confused... especially if there is a leak somewhere. So when you access a part, it loses the data that is in memory and crashes back to the desktop. So my guess is... and its only a guess... the garbage cleaning process is deleting things it shouldn't.

Programs do not magically start losing track of of their data once it gets over 4 GB.  In any case, plenty of people have reported crashes in stock installs which use significantly less than 4 GB.  Assuming that by "garbage cleaning process" you mean the Mono garbage collector, then it certainly isn't deleting things it shouldn't, it simply doesn't work that way.  You have to write some seriously hacky C# to cause the garbage collector to reclaim any memory that is still reachable by the program.  However, the Unity API does provide a couple of potentially dangerous functions (e.g. DestroyImmediate) which, if used incorrectly, can cause the Unity player to crash in nasty ways.  If I had to guess then I would say that some bit of KSP code is probably calling DestroyImmediate on a Unity object which happens to be being used by a background thread at the time and this causes corruption of memory resulting in dodgy pointers being passed to operating system functions and crashing.

Edited June 8, 2016 by Padishar

[deprav]

I'm experiencing that same issue as well. Where can I find the logs to post them next time it happens ?

I'll post my rig and OS next time, when I post a proper report.

[AlamoVampire]

@Claw Data Point: 22 minutes game play from clicking the yes, I trust it, now let me play in the UAC as admin. Note: Was in SPH tinkering with a design, specifically was adjusting the shuttle like wings and the same size strakes, had just deleted the strakes and went to adjust the wings and NTDLL.DLL said: NOPE. 

[MircoMars]

argh, I really go crazy over this issue! there seems to be no way to crash the game on purpose. the crashes seem to be connected to parts being detached from the vessel, both in VAB/SPH and atmo-flight. I don't remember a crash in vacuum, pls correct me if I'm wrong. but every time I try to repeat what crashed the game the last time it runs fine until it crashes at another point.

last thing I tried was running ksp_x64.exe on all cores but core0 and I had 3 hours of crashfree playing each with a clean stock install and my modded install. both times I built a craft in VAB with lots of radial attaching, detaching and deleting (which I thought of as the crashiest activity) and I was able to fly the mission just fine... either I got to the core of the problem (badumtss) or this issue just doesn't want to be debugged.

[Padishar]

12 hours ago, deprav said:

I'm experiencing that same issue as well. Where can I find the logs to post them next time it happens ?

This thread gives details of where to find the logs and what other information would be useful...

 

[MircoMars]

3 hours ago, MircoMars said:

either I got to the core of the problem (badumtss) or this issue just doesn't want to be debugged.

never mind, it's the latter....

[Claw]

Looks like we have tracked down the issue with this bug. I will say that with the help from the Kerbonauts out here, I was finally able to reproduce the issue in a reliable way. That was instrumental to ensure that we were looking in the right area and that the fixes addressed the problem. So thanks again to everyone who took time to track things down and post results here!

We're very optimistic that the issue is fixed, but also awaiting testing on a wider array of machines in Experimentals to ensure the issue is sorted.

Again, a big thanks to everyone for helping out in this thread.

[MircoMars]

1 hour ago, Claw said:

I was finally able to reproduce the issue in a reliable way.

can you please post how you did that? I guess some of us are eager to check your results and be able to work around that bug until a fix is released. 

since this bug seems to be affecting many but not all players, is it possible to test that fix even if we are not members of the experimental team?? I mean if you can release the bugfix without the other features for the next official release.

[Claw]

10 hours ago, MircoMars said:

can you please post how you did that?

I don't know that it will be definitively helpful for anyone, since the reproduction and susceptibility seems to vary so much per system and user. For me, the problem manifested itself when I would hold onto a part in 2x radial symmetry (any part, but I mostly tested with fuel tanks) and run it over a stack of two fuel tanks. Starting out by sliding the mouse from off a main stack fuel tanks, over the first tank, across the seam to the second fuel tank, then back off the main stack. It would take several iterations of this to cause the lockup and crash. The game would always crash when transitioning from one fuel tank to the next.

 

10 hours ago, MircoMars said:

I mean if you can release the bugfix without the other features for the next official release.

Unfortunately we can't release an update with only this change. The development process is such that it's effectively impossible (at this point) to pull that one fix and push it out as a release. And I use the term "one fix" loosely, because it was several iterations of work to achieve a stable solution. And that work is interspersed with other developmental work.

[AlamoVampire]

@Claw new data point in my on going "run as admin" experiment:

22 minutes from telling UAC to proceed with starting the game.

VAB was the location, was editing a rover that I want to send to Bop. Had just deleted a part off of it and tried to adjust a wheel location. Game decided after deleting that it was done. NTDLL.DLL came up on the post crash dialogue box.

hope these data points are helpful to you  

[MircoMars]

3 hours ago, Claw said:

-snip-

okay okay I get, I need to be patient... 

[11of10]

Guys, I'm using a heavily modded x64 on Windows 8.1, with 6GB RAM A4-5300 AMD CPU with integrated GPU, and had a lot of crashes until I disabled Steam's ingame overlay. Just went into options, and disabled it completely.

It actually crossed my mind that overlays could be a problem when a Viber desktop client popup crashed my game, even when I was in "Full screen" mode.

Anyone else tried this?

[dooots]

3 hours ago, Claw said:

For me, the problem manifested itself when I would hold onto a part in 2x radial symmetry (any part, but I mostly tested with fuel tanks) and run it over a stack of two fuel tanks. Starting out by sliding the mouse from off a main stack fuel tanks, over the first tank, across the seam to the second fuel tank, then back off the main stack. It would take several iterations of this to cause the lockup and crash. The game would always crash when transitioning from one fuel tank to the next.

I just want to say thank you for spending the time to find a way to make ksp crash for you.  Even with ksp crashing at a decent rate for me it still took several hours to find a fast crash, I can only imagine how many hours it took you to find that crash.

[Claw]

Oh, and I forgot to mention, the crash was repeatable at a much higher rate in the Tier 1 VAB than in the Tier 3. Sometimes it's all those microscopic details that make the difference.

[Rob2222]

7 hours ago, Claw said:

Unfortunately we can't release an update with only this change.

Hello Claw,
I can totally understand that you cannot push a update for one fix. But could you maybe offer it as downloadable hotfix for those who have issues with it? This would be nice.
When one has a install with much mods and loading times over 5 minutes, this issue is annoying.
BR Rob
 

[Padishar]

2 minutes ago, Rob2222 said:

Hello Claw,
I can totally understand that you cannot push a update for one fix. But could you maybe offer it as downloadable hotfix for those who have issues with it? This would be nice.
When one has a install with much mods and loading times over 5 minutes, this issue is annoying.
BR Rob

Surely the rest of the paragraph you quoted from makes it clear that this is "effectively impossible" and will not be done.  Just wait, if it's in QA now it will be in Experimentals shortly and you'll get it soon™. (And no, I'm not calling you Shirley)

[Rob2222]

Hmm,
for me are "pushing a new version out for that fix only" and "offer it as self download after QA test of the fix for those who have problems" two different things...
However, I hope for the steam dev version then.
BR
Rob

 

Edited June 9, 2016 by Rob2222