[Noted] Linux – End of Turn CTD

We’ve moved over to the paradox forums. Please come visit us there to discuss:
You can still read the collective wisdom - and lolz - of the community here, but posting is no longer possible.

Home Forums Update v1.5 – Open Beta Bugs [Noted] Linux – End of Turn CTD

This topic contains 5 replies, has 3 voices, and was last updated by  Lascha 7 years, 2 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #167263

    2McCoy7
    Member

    OS: Linux
    Beta Build: 15353

    I can only speculate but looking at the logfile my best guess is the crash was caused by a memory leak.

    I read your bug posting guide but this particular bug is useless without uploading the files below. If you don’t need one of them then don’t download it. Much easier having the correct files all in one place then trying to keep a folder for each bug just in case you might need them.

    Edit: Nevermind the forum did not let me upload .dmp or the save file.

    Attachments:
    1. log0316_1407.txt
    #167379

    Tombles
    Keymaster

    Hi 2McCoy7.

    Please could you email us the files to savegames@triumphstudios.com?

    Thanks!

    #168276

    2McCoy7
    Member

    I did not have all the correct files for that particular instance. I have sent you an email of another similar occurance.
    However I’ve been playing lots and the CTD’s do not seem to have pattern.
    Although the CTD’s seem to be more frequent while saving or ending the turn they have occurred during every action I can think of. Moving unit, upgrading unit, city upgrading ect. I have not yet had a CTD while the game was idle.

    I thought perhaps it was caused by a memory leak however this is not the case as I was monitoring it very closely. My total CPU usage was usually around 20% but maxed out at around 55% during peak and my memory held steady at 45% usage (3.5gb out of 7.8gb) <—I also created a 465GB swapfile just to see if that would make a difference. Nothing changed

    The only pattern I can see is the timeframe. 2-3 hours of play and it always seems to ctd. (Definitely a solid 2hrs and never more then 4hrs)

    ^^I can reload the last save and duplicate my last moves exactly and it NEVER causes a second CTD. It allows me to play again for 2-3 solid hours before it crashes

    #168377

    Lascha
    Moderator

    Thanks for reporting. The log says ‘Out of Memory!’ which actually means that memory allocation failed. According to the log it was when entering tactical combat. This is when it tries to allocate big chuncks of content to load.

    Possible reasons in your case:

    – Do you have a memory usage limit set for your application? Use the ulimit command to check

    – Since you said it happens after a few hours, my guess is that the cause is memory fragmentation by the OS: Memory isn’t available in big chuncks anymore, allocation fails, resulting in a crash (not sure what you can do about this). But note that our application is 32-bit, which means the maximum memory it can use is limited to 4GB even if you have more memory available. 64-bit applications solve this, but we don’t support that. Hopefully later we will. http://stackoverflow.com/questions/4863707/how-to-see-linux-view-of-the-ram-in-order-to-determinate-the-fragmentation

    – We have had similiar reports on Windows. It could be a leak. We have a case to look into this.

    #169420

    2McCoy7
    Member

    - Do you have a memory usage limit set for your application? Use the ulimit command to check

    After extensive research on ulimit and testing many variables I decided to simply set everything to unlimited and see what happens.

    core file size (blocks, -c) 0
    data seg size (kbytes, -d) unlimited
    scheduling priority (-e) 20
    file size (blocks, -f) unlimited
    pending signals (-i) 31838
    max locked memory (kbytes, -l) unlimited
    max memory size (kbytes, -m) unlimited
    open files (-n) 1024
    pipe size (512 bytes, -p) 8
    POSIX message queues (bytes, -q) 819200
    real-time priority (-r) 0
    stack size (kbytes, -s) unlimited
    cpu time (seconds, -t) unlimited
    max user processes (-u) unlimited
    virtual memory (kbytes, -v) unlimited
    file locks (-x) unlimited

    ^^With those settings the game does not CTD anymore, it completely freezes instead. I have the monitoring application htop running in the background and there are zero spikes in memory usage (2.5gb out of 8gb). This is down from my last report as I went through all the startup applications and removed all the fluff to see if it would make any difference. Unfortunately no noticeable differences besides the game freezing. The cpu % does not spike either, even when its frozen the levels are the same.

    One thing I did notice in the logs before and after the ulimit changes was this line

    [20:34:40]EGetMemoryInfo not supported on this platform…
    ^^This line pops up like 5-8 times in each logfile

    If I am reading this correctly the game just might not be meant to run in my particular distro. If I am correct in this assumption has the game been test on SteamOS? If I have to dual boot I would much rather use the OS designed for gaming rather then Ubuntu…

    Thanks for taking the time to read this!

    #169497

    Lascha
    Moderator

    Hmm. I think the fact that ulimit had an effect means that the earlier limit was actually being reached.

    [20:34:40]EGetMemoryInfo not supported on this platform…
    ^^This line pops up like 5-8 times in each logfile

    That’s not a problem; it’s purely for profiling/debugging the memory usage.

    It has not been tested on SteamOS, but this is high on our list. Though it should just work on Ubuntu too. Since it always happens after a few hours this leads me to believe there’s a memory leak. This is something we have yet to look into though.

    Thanks again. 🙂

    PS. It would help, memory-wise, if you could set the texture quality lower than your current setting; this affects memory usage significantly. It might help.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.