Sprite enable/disable crash

Bugs
1

I report to you that the game may crash when enable/disable sprites
with high frequency in Windows.
I don’t use any native extensions.

I have uploaded a crash dump.
I’ve organized the crash dump contents into folders.
Sometimes a crash dump may not be generated.

Removing the following message processing will prevent the crash.

msg.post(“#sprite”, “enable”);
msg.post(“#sprite”, “disable”);

The exact conditions are unclear, but it occurs when enable/disable sprites of GOs generated from the factory.
This issue seems more likely to occur when multiple GO instances are enable/disable simultaneously.

Please let us know if there is any missing information.

2

The crash dmp shows 1.12.4. Did the crashes start when you updated to 1.12.4 or is it also crashing in earlier versions?

Could you please share a minimal project where the problem can be observed?

Crash dump from one of the submitted crashes:

 0 0x7FF6DCF7D660 dmCrash::GenerateCallstack D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:143
 1 0x7FF6DCF7DD00 dmCrash::SignalHandler D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:294
 2 0x7FF6DD3043B0 raise /tmp/job8836588226779056954/minkernel/crts/ucrt/src/appcrt/misc/signal.cpp:547
 3 0x7FF6DD2F4624 abort /tmp/job8836588226779056954/minkernel/crts/ucrt/src/appcrt/startup/abort.cpp:71
 4 0x7FF6DD2F333C common_assert_to_stderr<wchar_t> /tmp/job8836588226779056954/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:186
 5 0x7FF6DD2F2E58 _wassert /tmp/job8836588226779056954/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:443
 6 0x7FF6DCEFCF10 dmRender::DrawRenderList D:\a\defold\defold\engine\render\src\render\render.cpp:1036
 7 0x7FF6DD0F7910 dmRender::ParseCommands D:\a\defold\defold\engine\render\src\render\render_command.cpp:185
 8 0x7FF6DD004C50 dmRender::UpdateRenderScriptInstance D:\a\defold\defold\engine\render\src\render\render_script.cpp:3656
 9 0x7FF6DCFF0FE0 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:2086
10 0x7FF6DCFEADF0 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2620
11 0x7FF6DCFF1D60 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:86
12 0x7FF6DCECEE00 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:153
13 0x7FF6DD2ABDE4 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
14 0x7FFA1223E940 BaseThreadInitThunk <unknown>:0
15 0x7FFA13D64250 RtlUserThreadStart <unknown>:0
3

This issue has been confirmed to be reproducible up to version 1.12.0.
It has not been confirmed to be reproducible in earlier versions.

The reason the crash is occurring is that the Sprite-related processing, which appears to be the direct cause of the crash, is being executed in late_update().
Moving this processing to fixed_update() prevents the crash from recurring.

I also tried a minimal project "TestPJ ", but I were unable to reproduce the issue.
I push TestPJ for your reference.
TestPJ is structured similarly to the original project, with enemy constantly sending messages to shadow.
Removing Sprite enable/disable handling the “size” message in shadow.script temporarily prevents the crash.

4

I don’t understand. Does it crash in TestPJ or not?

5

Sorry, TestPJ hasn’t been able to reproduce the issue.
TestPJ is just to explain what processes are being executed around where the issue occurs.

6

Could you please create an issue on GitHub with the information in this post? This way we have the information saved for the future in case someone else manages to find a good way to reproduce the issue.

7

I created issue on GitHub.

8

Thanks!
Would it be possible for you to attach a repro project to the ticket?

9

I’m sorry, but I can’t upload repro project that are still under development.

Even reproducible minimal project take time, so I can’t prepare it.

Testing the modified Defold is possible.