Subj.
When game is paused (there's still a memory leak with time passed without pause, thus checked with pause on, but that's different I think) if you repeat opening/closing inventory (just spam 'i' with default key config) there's a memory leak which will lead to crash eventually.
Happens in new game, using steam version. Game was verified when 66.2 patch rolled in (by deleting data folder and verifying cache), so it's not a problem.
Reproducing a crash requires too many clicks usually and I can't make macro to work, so no crash dump for now.
Happens as of 0.66.2
EDIT: still happens as of 0.70.0 (at least on x64 version, most likely on both versions).
[0.70.0]Opening/closing inventory causes memory leak.
I managed to make a macro to spam 'i' button and thus reproduced issue with crashing. (Load any game/create new game -> spam 'i')
Still happening at 0.67.0 version. (data folder deleted and verified), but now I got a bit different error before default crash dump message.

Crash dump attached (dump failed, so .dmp file is empty in archive), but there's a mention in OGRE log that video memory ended.
Average memory leak is 1 Mb per one cycle open/close inventory.(1000 clicks of 'i' give 500 cycles and it leaks a little bit less than 500 Mb); have not checked if depends on what inventory holds. Can try to check if you require.
Symptoms of leak: memory usage increases when watched using task manager. Kenshi crashes when memory usage 3.7+Gb, never crashes before.
System specs(if needed):
64 bit windows 7;
CPU: AMD A8 - 5600K APU
16 Gb RAM
GPU: Geforce GTX 660 Ti with 2048 Mb dedicated memory and 4096 Mb total available.
Can provide any additional info you will ask for/can conduct additional tests.
Still happening at 0.67.0 version. (data folder deleted and verified), but now I got a bit different error before default crash dump message.

Crash dump attached (dump failed, so .dmp file is empty in archive), but there's a mention in OGRE log that video memory ended.
Average memory leak is 1 Mb per one cycle open/close inventory.(1000 clicks of 'i' give 500 cycles and it leaks a little bit less than 500 Mb); have not checked if depends on what inventory holds. Can try to check if you require.
Symptoms of leak: memory usage increases when watched using task manager. Kenshi crashes when memory usage 3.7+Gb, never crashes before.
System specs(if needed):
64 bit windows 7;
CPU: AMD A8 - 5600K APU
16 Gb RAM
GPU: Geforce GTX 660 Ti with 2048 Mb dedicated memory and 4096 Mb total available.
Can provide any additional info you will ask for/can conduct additional tests.
- Attachments
-
- crashDump0.67.0.zip
- (29.68 KiB) Downloaded 261 times
Have you tried a soak test (leave Kenshi running on unattended machine for several hours) to see if it eventually produces similar results over a longer period of time, yet?
It seems, to me, that a lot of actions in Kenshi (in your case its spamming "i") tend to create temporary values that are never scrubbed by a garbage collector or other means to reduce memory usage.
If I had access to core code, I'd just put in some debug statements wherever temp values are created and see if any of these values are not being cleaned properly after the function, or their usefulness, ends.
Is it possible to append debug statements to mods to display text on screen whenever things occur in the background (such as spawning NPCs or other things that are moddable)?
This could be used to narrow down some of the memory leaks, I bet.
It seems, to me, that a lot of actions in Kenshi (in your case its spamming "i") tend to create temporary values that are never scrubbed by a garbage collector or other means to reduce memory usage.
If I had access to core code, I'd just put in some debug statements wherever temp values are created and see if any of these values are not being cleaned properly after the function, or their usefulness, ends.
Is it possible to append debug statements to mods to display text on screen whenever things occur in the background (such as spawning NPCs or other things that are moddable)?
This could be used to narrow down some of the memory leaks, I bet.
Tests with inventory open/close were conducted with pause. No memory leaks with leaving game running with pause on for an hour-two.PnzrNorm wrote:Have you tried a soak test (leave Kenshi running on unattended machine for several hours) to see if it eventually produces similar results over a longer period of time, yet?
It seems, to me, that a lot of actions in Kenshi (in your case its spamming "i") tend to create temporary values that are never scrubbed by a garbage collector or other means to reduce memory usage.
If I had access to core code, I'd just put in some debug statements wherever temp values are created and see if any of these values are not being cleaned properly after the function, or their usefulness, ends.
Is it possible to append debug statements to mods to display text on screen whenever things occur in the background (such as spawning NPCs or other things that are moddable)?
This could be used to narrow down some of the memory leaks, I bet.
Memory leak still occurs if inventory is being opened by mouse clicking on "Inv" button, I use 'i' for simplicity.
I don't know about Kenshi mod capabilities, but I believe it's picture-related. Inventory being filled with pictures and those pictures not being cleared from video memory by OGRE causing video memory overflow and crash. That is the only explanation I see why Kenshi would crash on 3.7 Gb sometimes, and sometimes on 3.8 Gb RAM used while being fine(yet) at 3.7 Gb and that would explain OGRE's log about video memory lack.
But I might be wrong in my guess, as it's good as any without sources. The fact is: memory leak is there, and can be reproduced easily.
Does happen with any container that has anything inside.
Does happen with any container that doesn't have anything inside, but it leaks much less amount of memory.
Does depend on amount of item stacks in container(from 4 kb per container per open/close with 2x3 empty container to 1 Mb per open/close on Large shop counter filled with bread/rum stacks)
Does happen with any container that doesn't have anything inside, but it leaks much less amount of memory.
Does depend on amount of item stacks in container(from 4 kb per container per open/close with 2x3 empty container to 1 Mb per open/close on Large shop counter filled with bread/rum stacks)
Just encountered a crash with the error: A device attached to the system is not functioning
- Attachments
-
- crashDump0.67.0.zip
- (302.34 KiB) Downloaded 195 times
Another "device attached to the system is not functioning" super crash.
- Attachments
-
- crashDump0.67.0.zip
- (295.79 KiB) Downloaded 144 times
Bump: still happens as of 0.70.
Managed to get x64 version RAM usage up from 2 Gb to 3.5 Gb in two minutes from spamming 'i' with script. Not causing crash on x64 system, but memory leaks pose a possible performace problem. But if bug is still present on x86 systems, most likely is will crash.
Managed to get x64 version RAM usage up from 2 Gb to 3.5 Gb in two minutes from spamming 'i' with script. Not causing crash on x64 system, but memory leaks pose a possible performace problem. But if bug is still present on x86 systems, most likely is will crash.
- Captain Deathbeard
- Developer
- Posts: 1831
- Joined: Thu Jul 03, 2008 12:04 pm
- Location: UK
- Contact:
It's not a problem.
The "delete"s are put in a queue for deletion later, with a timer delay (20 secs). When you call the inventory rapidly, it's constantly adding to the queue and resetting the timer, so it overloads. In other words, it only leaks when you do what you are doing, but should be fine under normal gameplay.
The "delete"s are put in a queue for deletion later, with a timer delay (20 secs). When you call the inventory rapidly, it's constantly adding to the queue and resetting the timer, so it overloads. In other words, it only leaks when you do what you are doing, but should be fine under normal gameplay.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 5 guests