dmBuffer::Create() crash (DEF-3761)

[sergey.lerg]

Looks like dmBuffer::Create()is not thread safe. Sometimes it crashes in my recent extension https://github.com/Lerg/extension-imageloader/blob/master/imageloader/src/extension.cpp#L73

And only during app start. Haven’t seen this when the app has successfully launched.

Assertion failed: (ctx->m_Buffers[index] == 0), function SetBuffer, file ../src/dlib/buffer.cpp, line 125.

Here is crash report dmbuffer_crash.lua (60.4 KB)

What can I do about that?

[britzl]

I’ll let @Mathias_Westerdahl or @sven answer this.

[selimanac]

Probably the same, Lua isn’t thread safe :

"Assertion failed" with Native Extension on iOS when invoke callbacks (Solved)

I couldn’t figure it out how to safely invoke lua callbacks from c++ thread. Little info; I’m developing a NE for our multiplayer game using uWebSockets and msgpack(it may change). Every socket connection has its own “thread” with lua callbacks like onConnect, onError, onMessage… I’m using two threats for now but it will be just one. Everything works fine on desktop(mac) even when I hard on it. I believe it is because the processor speed. But on ios(ipad 3 - ARMv7) I have bunch of “Assertion…

"Assertion failed" with Native Extension on iOS when invoke callbacks (Solved)

There are various ways to deal with communicating between threads. One way we use is to post commands to a shared data structure, that you can then process in your UpdateExtension function.
Here’s such an example (https://github.com/defold/extension-admob/blob/master/admob/src/googlemobileads.cpp), although it should be noted that there too is an issue. In fact, we don’t protect that data queue with a lock of some kind (E.g. a mutex). To make sure that the data structure isn’t modified from two threads at once, you need to protect it.

[sergey.lerg]

It’s similar stuff. I already don’t invoke Lua stuff on a thread, when I am invoking a callback, I do so on the main thread inside the update function.
But Defold’s internal stuff can be accessed in other threads, it’s just some things are not thread safe. Here I am creating a new buffer object at the same time when the engine creates other buffer objects.

if I could set up a mutex or precreate the buffer object on the main thread, that would solve the problem. But mutex has to be incorporated in the engine and I can’t easily precreate the buffer object, because it needs buffer size value, and I know the size only inside the thread when image is being loaded.

So if there is a way to resize the buffer object after creation, that would solve the issue. Or maybe there is some other smart solution. If not, I will have to rework my threading code to invoke dmBuffer::Create() on the main thread.

[Mathias_Westerdahl]

Yes, looking at the code, it seems the code isn’t thread safe. There is no real reason why it shouldn’t be.
I’ve added DEF-3761 for this.

[sergey.lerg]

Awesome, thanks!