bevy memory usage grows over time

[Byteron]

Bevy version

0.8

What went wrong

I left a bevy app running in the background for a long time, and well, it grew to 12 GB memory usage over the course of ~8 hours.
The App is just a few planes and a simple controller system.

It seems that a bevy app just with the default plugins and nothing else also grows over time, so it's not my code but a bevy problem.

[alice-i-cecile]

This has been examined before; IIRC this is the result of logging enabled during debug builds.

[Byteron]

I can confirm that this is only happening in debug builds. when cargo run --release the mem usage is not growing.

[afonsolage]

I let a game with only Default plugins running for some time, with cargo run --release on Windows 11 and it is still increasing memory usage.

use bevy::prelude::*;

fn main() {
    App::new().add_plugins(DefaultPlugins).run();
}

On startup

1 hour later

3 hours later

7 hours later

Running Time	Memory Usage
0h	65.9 MB
1h	150.6 MB
3h	436.3 MB
7h	73.9 MB

Edit: It seems this is some internal memory/cache pool. I noticed when it was about to reach 500 MB it dropped to ~50 MB again and restarted the cycle.

So I don't think there is a memory leak.

[alice-i-cecile]

Moving this to a docs issue then :)

[bjorn3]

It seems this is some internal memory/cache pool. It noticed when it was about to reach 500 MB it dropped to ~50 MB again and restarted the cycle.

Does it also drop down in case of memory pressure from other program? If so, that should be fine, if confusing for end users. If not, it is probably still an issue.

[afonsolage]

It seems this is some internal memory/cache pool. It noticed when it was about to reach 500 MB it dropped to ~50 MB again and restarted the cycle.

Does it also drop down in case of memory pressure from other program? If so, that should be fine, if confusing for end users. If not, it is probably still an issue.

It was using around 800MB and then I launched 15 wasm bevymark with 500k sprites each to force Chrome do what it does better: eating ram. Then reflect_example, which is the program that is running for about 12hs, dropped it's memory to about 100MB.

After a while it crashed, since the Windows ran out of ram:

memory allocation of 9591008 bytes failed
error: process didn't exit successfully: `target\release\reflect_example.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

[hammypants]

This has been examined before; IIRC this is the result of logging enabled during debug builds.

Is there a way to disable this?

fn main() {
    App::default().add_plugins_with(DefaultPlugins, |group| { group.disable::<bevy::log::LogPlugin>() }).run();
}

Still grows at an exceptional rate with cargo run.

[alice-i-cecile]

Yep, we're getting another memory leak over in #6417: the logging is a factor, but far from the only issue.

[james7132]

#6878 seems to fix the issue seen in #6417. @Byteron can you check if it fixes this leak?

[Yairama]

Maybe this will help someone, that's why I'm commenting.

When I installed Vulkan, I started to get a Validation layers error, an error that does not stop the execution but causes a slight increase in memory over time.
The error was:

ERROR wgpu_hal::vulkan::instance: VALIDATION [UNASSIGNED-CoreValidation-Shader-InconsistentSpirv (0x6bbb14)] Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0x24ebcd349f0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: [VUID-StandaloneSpirv-OpTypeRuntimeArray-04680] Vulkan, OpTypeStruct containing an OpTypeRuntimeArray must be decorated with Block or BufferBlock. %PointLights = OpTypeStruct %_runtimearr_PointLight

It was solved by removing vulkan completely.

[TotalKrill]

On webbrowsers this results in crashed tabs after the app has been running for a while. However, we seem to be able to work around this by using:

DefaultPlugins.build()
         .disable::<LogPlugin>()
         .disable::<DiagnosticsPlugin>();