(1.6.1 MH) Does this lunar base crash your Linux client?

[securityinstruts]

Hi all,
This is my first take on making semi-permanent research& miner base on the Mun with small Munar orbital refueler but i have been suffering some crashes after creating it and thus testing actual performance is lacking.

Would love if Linux users would try this out and report how they fare since cant get any error codes myself. Client either mysteriously disappears or terminal hangs with ~450kb memory usage(forcing it to close causes system to freeze up) and no logs are generated... or then just find them myself These problems occur more frequently on Mun and of course everybody should feel free to try if they decide so

Using

System

Linux Mint 18 Sarah 64-bit

Kernel 4.4.0-135-generic

Nvidia 410.78

• KSP version 1.6.1.2401
• Making History version 1.6.1
• Craft from KerbalX

If Jeb sometimes tries something un-usual when piloting, then Bill has the same urge to show off while supervising operations
Bill doing a stand-still wheelie -from imgur Look at the silly bugger =)
https://imgur.com/ujzdItu

 

 

 

[steve_v]

11 hours ago, securityinstruts said:

Craft from KerbalX

Directs me to a login page. Craft page link?

Does the craft actually require MH? If so, I can't test it anyway.

Edited February 20, 2019 by steve_v

[Daveroski]

I have linux mint too. But I don't have MH so sorry, can't help you.

 

[securityinstruts]

Sorry about that... i'm so green with this ;-)
Try downloading it from kerbalx through this link. I do hope users can DL without signing in.. if that does not allow you to DL it then, im oh-so happy to hear about alternative upload places or else we have to get creative

Does it require MH... im totally, happily, clueless about this since haven't started client without MH but i didn't use any sensational crew modules or such

[Green Baron]

This question actually made me download and install KSP again, since a long time :-)

First: the craft wouldn't load in a Linux stock 1.6.1. sandbox game due to missing parts.

If you are suffering crashes it is in principle a good idea to look at all the available logs, from KSP and the OS. Start the program from a terminal, even it is only for a lapidary "Segmentation fault" message in the end. Look at the KSP log, see OS's logs in /var/log. Without further info it is impossible to corner the error, if one exists. You can put the question in the support section of the Making History expansion (which i do not own).

Sorry ...

[Geonovast]

You're not looking at a Linux issue, which I was 99.99% sure of anyway, but I did play around with the ship.

I got it up to a ~ 106km x 106km orbit just fine.  Yellow clock the whole way, but the only real issue was a good number of explosions when staging the first time.

Without even getting into the design issues, I have a feeling that your problems are that your computer simply doesn't like doing physics on a 527 piece, 2,500 ton ship.

You listed your OS, driver, and kernel specs, but you didn't tell us what's actually important - CPU, GPU, Memory, and Desktop/Laptop.

This was done on my backup computer since my main one is under the knife right now:

• Linux Mint 18.3/MATE
• 4.15.0-43 kernel
• Nvidia 384.130
• i5-7500 @ 3.8 ghz.
• 32 GB DDR4-2400
• 4GB GTX 1050Ti
• GOG version of the game (1.6.1 MH)

 

 

Edited February 21, 2019 by Geonovast

[securityinstruts]

On 2/20/2019 at 4:29 PM, Green Baron said:

This question actually made me download and install KSP again, since a long time :-)
First: the craft wouldn't load in a Linux stock 1.6.1. sandbox game due to missing parts.

Thank you for confirming that this craft needs MH ! Sorry, my bad for not realizing it, and will try to mod previous posts to state this, but clad that could give reason to play again =)
Trying to find any memory problems but so far no success.

@Geonovast you are right, I did exclude those details for possible future support request =)

• i5-3570K CPU @ 3.40GHz × 4
• 16GB DDR-1333 -have had issues before, thus lower clock
• 2GB GTX 660

Client uses about 3,4GB memory and  ~60% of CPU while GPU goes with ~70% cycles and bit over 600MB.. temps are okay and no errors to be found after client disappears This is like 7-6 years old custom build desktop with its own problems =D If launched from terminal, said terminal just hangs -can't find that memory trace, many halps needed And most of all.. how do you add pictured /have pictures instead of link to be shown?

Managed to fumble my local file save so had to DL uploaded and.. G-Damn! Battery power does not last over night and nuclear engines drained upper stage but managed  finally to touchdown only to discover that this version does not have enough cooling power
https://imgur.com/a/fuDRl8t

Edited February 21, 2019 by securityinstruts

[norup]

I took it up to a 250x200km Kerbin orbit on the solid boosters and chemical rockets without encountering problems - but frame rate was rather low.

Ubuntu 18.04.2 LTS

Intel® Core™ i5-4590 CPU @ 3.30GHz × 4 , 8Gb RAM, GeForce GTX 960/PCIe/SSE2, NVidia driver 390.77

 

 

 

[securityinstruts]

Happy to see more people using alternatives with their hardware =)

I can land it on Mun and even start mining but sooner than later client crashes.. been trying to inch save closer to being refueld but having no such luck or endurance with these temps .. Whomever designed this thing clearly didn't test it

Tried launching from terminal with __GL_GlslUseCollapsedArrays=0 ./KSP.x86_64 and log managed to log latests events
   Snips from
  

Spoiler

Player.log

[F: 89956]: [00:00:00]: Liftoff!!
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

[ContractParameter]:  on Contract Build a new surface outpost on The Mun. set to Incomplete.
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Receiving unhandled NULL exception
#0  0x007fff19c798c0 in funlockfile
#1  0x007fff19c79e78 in std::map<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> >, std::less<core::basic_string<char, core::StringStorageDefault<char> > >, std::allocator<std::pair<core::basic_string<char, core::StringStorageDefault<char> > const, core::basic_string<char, core::StringStorageDefault<char> > > > >::~map()
#2  0x007fff19c79e80 in std::map<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> >, std::less<core::basic_string<char, core::StringStorageDefault<char> > >, std::allocator<std::pair<core::basic_string<char, core::StringStorageDefault<char> > const, core::basic_string<char, core::StringStorageDefault<char> > > > >::~map()
#3  0x007fff19c79ee0 in std::map<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> >, std::less<core::basic_string<char, core::StringStorageDefault<char> > >, std::allocator<std::pair<core::basic_string<char, core::StringStorageDefault<char> > const, core::basic_string<char, core::StringStorageDefault<char> > > > >::~map()
#4  0x007fff19c79f20 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#5  0x007fff19c7a040 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#6  0x007fff19c7a0c0 in operator new(unsigned long)
#7  0x007fff19c7a140 in operator new(unsigned long)
#8  0x007fff19c7a7f0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#9  0x007fff19c7a840 in std::map<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> >, std::less<core::basic_string<char, core::StringStorageDefault<char> > >, std::allocator<std::pair<core::basic_string<char, core::StringStorageDefault<char> > const, core::basic_string<char, core::StringStorageDefault<char> > > > >::~map()
#10 0x007fff19c7a900 in operator new(unsigned long)
#11 0x007fff19c7a9c0 in operator new(unsigned long)
#12 0x007fff19c7aa80 in operator new(unsigned long)
#13 0x007fff19c7acb0 in operator new(unsigned long)
#14 0x007fff19c7ade0 in operator new(unsigned long)
#15 0x007fff19c7ae30 in operator new(unsigned long)
#16 0x007fff19c8b030 in operator new(unsigned long)
#17 0x007fff19c8b070 in operator new(unsigned long)
#18 0x007fff19c8b920 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#19 0x007fff19c8b960 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#20 0x007fff19c8b980 in zcfree
#21 0x007fff19c8c7e0 in __libc_start_main
#22 0x007fff19c8c8a0 in zcfree

 

Spoiler

Terminal output

	/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xef) [0x7f354ff9182f]
	./KSP.x86_64() [0x45eb68]

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.
=================================================================

Aborted

 

So, I get this feeling that most likely this problem is at my end

Any ideas about tracing this problem are welcome





 

 

Edited February 26, 2019 by securityinstruts
finally a picture and recent update