Godot 3.3 editor locks dll for writing (GDNative)

[sisterhooddev]

Godot version:
3.3

OS/device including version:
Windows 8.1

Issue description:
Godot Editor locks dll forcing user to restart editor to overwrite dll.
I think something was changed how Godot is terminating process of running scenes, cos it started to throw some memory errors at get_tree() exit() that I fixed in destructor, but this wasnt happening in older versions.

Steps to reproduce:
Run scene with GDNative script in Godot Editor. Close it. Now gdnative dll is locked by Godot editor and you cant change it unless you restart Godot.

[Calinou]

@sisterhooddev Can you reproduce this in 3.2.3?

[sisterhooddev]

I tested all 3.2.4/3.3 versions.

Crashing at exit, that I can fix or not, started from 3.2.4 beta1. EDIT: But this crash seems to be random now.
EDIT2: Crashing is gone now. When updating to 3.3 I also updated godot-headers and maybe crashing was occuring because VS didnt fully rebuild the project and now is rebuilded.

Godot editor locking dll started from 3.2.4 rc1

[sisterhooddev]

Issue is gone in 3.3.1 rc1

[Calinou]

Closing per @sisterhooddev's comment.

[sisterhooddev]

I am sorry, but it looks like its not gone.

Something really weird is going on in windows.

I tried import my project in 3.3.1 and it was crashing firstly after opening project scene. When I opened project in 3.3 rc6 crash after start was gone but it started crashing on exit just like in isssue #48295, but Godot wasnt locking dll for writing.
Now it is not crashing all but Godot is locking dll.

EDIT: is Godot creating any temp files for project somewhere, cos it makes no sense why it is crashing and crash is gone somehow?

EDIT2: So Godot is creating project files in User\AppData\Roaming\Godot\projects
Good to know to delete those when opening project in new version.

[ghost]

Can confirm, on 3.3.1 creating an empty GDNative project with a single class that calls get_tree()->quit() in _ready segfaults editor in a way that I cant even acquire proper callstack on two different machines. All I have so far is Unhandled exception at 0x000007FEEE255490 in EDITOR.EXE: 0xC0000005: Access violation executing location 0x000007FEEE255490. This is how the end result looks like:

[ghost]

GDB trace is not helping either, this version of the engine is compiled in debug and this is still the result:

[ghost]

After manually stepping over code in a debugger I found out that the culprit is free_instance_binding_data, which is a direct cause of previously mentioned #48295 and also of this issue about file locking, since if the game is run in the editor then this error is not being properly handled, which results in editor locking the DLL.

[akien-mga]

Is this still reproducible in 3.5 beta 5 or later?

[sseeland]

I don't know about 3.5 but I can definitely reproduce it with GDExtension on he current 4.0 master branch... Not sure if it's the same bug, because one is GDNative and the other is GDExtension. I'll gladly open a separate issue if that's the case.

[joelgwebber]

I'm seeing this on 4.0 alpha 14 (and master) as well. The dll is locked for writing by the editor, forcing you to terminate it in order to rebuild. I'm not certain whether this is intentional, but it does make the development cycle awkward. It would be significantly improved if the dll wasn't locked, and the editor could reload the extension, either manually or when the shared library changed.

[Bromeon]

For Godot 4, reloading (without DLL locking) has been implemented in #80284 and #80188.

So the question remains whether latest 3.x still suffers from this?