Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Material Override data not freed if set from script #12401

Closed
ghost opened this issue Oct 25, 2017 · 1 comment · Fixed by #12784
Closed

Material Override data not freed if set from script #12401

ghost opened this issue Oct 25, 2017 · 1 comment · Fixed by #12784
Labels
bug topic:core
Milestone
3.0

Comments

@ghost
Copy link

ghost commented Oct 25, 2017 •
edited by ghost
Loading

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Linux Godot 3.0@4396712

Steps to reproduce:

  • Create quad mesh with SpatialMaterial in Material Override
  • Set texture via script (tried albedo_texture and normal_texture)
  • Runing outside of editor, when exiting it produces:
WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:1858.
ERROR: clear: Resources Still in use at Exit!
   At: core/resource.cpp:388.

This issue does not occur with surface Material.

EDIT: Seems to affect every data passed to material_override with script

Link to minimal example project:
leak_tests.zip
@ghost ghost changed the title Material Override textures not freed if set from script Material Override data not freed if set from script Oct 25, 2017
@akien-mga akien-mga added this to the 3.0 milestone Nov 1, 2017
@hpvb hpvb mentioned this issue Nov 9, 2017
Merged
@hpvb
Copy link
Member

hpvb commented Nov 9, 2017

The noted PR seems to fix this issue

[hp@lola leak_tests]$ ~/Projects/workspace/godot/bin/godot.x11.opt.tools.64 --path .
OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
[hp@lola leak_tests]$ ~/Projects/workspace/godot/bin/godot.x11.opt.tools.64 
OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile
[hp@lola leak_tests]$ ~/Projects/workspace/godot/bin/godot.x11.opt.tools.64 
OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ARVR: Registered interface: Native mobile

No more warning! :)

hpvb added a commit to hpvb/godot that referenced this issue Nov 9, 2017
@hpvb
Make sure we don't leak when an opcode is followed by itself
38ae49e 
When compiling with GCC it is now possible for an opcode followed by
itself to never leave the scope it is currently in. This leads to a
situation where the dtor of a scope local variable isn't called which in
turn can lead to a memory leak.

By moving the goto outside of the scope of each opcode we guarantee that
all dtors have been called before the next opcode gets dispatched.

this fixes godotengine#12401
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug topic:core
Projects
None yet
Milestone
3.0
Development

Successfully merging a pull request may close this issue.

Make sure we don't leak when an opcode is followed by itself hpvb/godot
2 participants
@hpvb @akien-mga