[unity3d] [steam] Player.log grows up to hundrets of gigabytes

[Boeroer]

Hi,

 

I'm playing Deadfire under Linux (Ubuntu 18.04.1 LTS; Intel Core i7-7700K CPU @ 4.20GHz × 8; GeForce GTX 1080/PCIe/SSE2; 64bit)

 

The Player.log starts with this:

 

 

Setting breakpad minidump AppID = 560130
Steam_SetMinidumpSteamID:  Caching Steam ID:  47113508074350777 [API loaded no]
ERROR: ld.so: object '/home/boeroer/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/boeroer/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/boeroer/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/boeroer/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/boeroer/.steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

and then there will be this log entry which gets repeated endlessly:

 

Unhandled Exception: System.InvalidOperationException: Handle is not allocated
  at System.Runtime.InteropServices.GCHandle.get_Target () [0x00000] in <filename unknown>:0 
  at System.WeakReference.get_Target () [0x00000] in <filename unknown>:0 
  at Onyx.OnyxObject.Finalize () [0x00000] in <filename unknown>:0 

Until my disk is full and the file has more than 140 GB (the time I discovered the problem). I am the only one who experiences this? Edited August 31, 2018 by Boeroer

[Boeroer]

Nobody? Weird. So this seems to be a problem of my system rather than one of Unity3D/Deadfire?

[MaxQuest]

You seem to be using the wrong elf, duh. Try using the correct one

 

On serious note: I don't even have Player.log generated on steam/windows.

But here are 2 ideas:

- try disabling steam overlay for Deadfire: howto

- if that doesn't help... you can symlink the Player.log to /dev/null as posted by ShadowApex here

 

P.S. Dunno it it's of any help, but here's the code for Onyx.OnyxObject.Finalize():

 

 

protected override void Finalize()
{
    try
    {
        WeakReference weakReference = null;
        if (this.m_persistentOnyxObject != null && OnyxObject.s_allObjects.TryGetValue(this.UniqueID, out weakReference) && weakReference != null && weakReference.Target == this)
        {
            OnyxObject.s_allObjects.Remove(this.UniqueID);
        }
        this.DecrementOnyxBehaviorCount();
    }
    finally
    {
        base.Finalize();
    }
}

 

Edited September 1, 2018 by MaxQuest

[Boeroer]

Thanks MaxQuest! I'll check it out.

 

For the time being there's an easy workaround: I just delete the file with a script on bootup.  If something happens and I want to look up the log I can still do that - but it will be gone once I power up the computer. 

 

Also funny that I didn't find that thread you pointed me to - because I was searching for "Player.log" in this very subforum before posting...? Is the search case-sensitive? Nay that can't be it... Well I got a ton of hits because of the word "Player" and I didn't manage to search for player.log specifially (search function also shows results for "player" OR "log"), so maybe I missed it. Thanks again!

Edited September 1, 2018 by Boeroer

[MaxQuest]

Also funny that I didn't find that thread you pointed me to - because I was searching for "Player.log" in this very subforum before posting...? Is the search case-sensitive? Nay that can't be it... Well I got a ton of hits because of the word "Player" and I didn't manage to search for player.log specifially (search function also shows results for "player" OR "log"), so maybe I missed it. Thanks again!

Majority of forum search engines are so so)

 

MaxQuest uses google-fu. It's super effective

google.com/search?q=site:forums.obsidian.net+"Player.log"

[Boeroer]

Yeah, I should have known better. The google (site) search is nearly always superior.