Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.9K All Categories
- 12 Help with translations
- 4.3K General questions
- 107 Roadmap
- 360 Game & application design
- 322 Plugins
- 71 User experience
- 75 Marketplace
- 294 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 354 Announce your apps made with Gideros.
- 91 Step by step tutorials
- 682 Bugs and issues
- 195 Introduce yourself
- 247 Announcements
- 107 Forum talk
- 405 Relax cafe
Crashes in Background Thread
troysandal
Member
Gideros - 2025.3
Machine - M1 Max Macbook Pro
OS : macOS Sequoia 15.7.3
I’m experiencing a crash on application startup and need some help. Here’s what’s happening. During startup my application is making a lot of nested calls to both Parse backend and various AppKit APIs, all through a Wax bridge. In my crash scenario I’ve called PFGeoPoint:geoPointForCurrentLocationInBackground() with a Lua callback function. As Lua is preparing to call the callback, I get a crash. Sometimes in the main thread (Thread 1) but sometimes in Thread 21. The stack traces always vary but what they all have in common is that Thread 21 is also executing Lua code called from Gideros LuaApplication::broadcastEvent. Both threads are using the same lua_State* L pointer.
Pictures of the stack traces are below. I have 2 ideas currently. First, this is a problem I introduced with my changes to BhWax. Second, we have 2 native threads modifying the same lua_State pointer and crashing. I am leaning towards the second idea because as far as I can tell, Lua states are NOT thread safe.
If anyone has any ideas I would love to hear it. Thanks in advance.
Machine - M1 Max Macbook Pro
OS : macOS Sequoia 15.7.3
I’m experiencing a crash on application startup and need some help. Here’s what’s happening. During startup my application is making a lot of nested calls to both Parse backend and various AppKit APIs, all through a Wax bridge. In my crash scenario I’ve called PFGeoPoint:geoPointForCurrentLocationInBackground() with a Lua callback function. As Lua is preparing to call the callback, I get a crash. Sometimes in the main thread (Thread 1) but sometimes in Thread 21. The stack traces always vary but what they all have in common is that Thread 21 is also executing Lua code called from Gideros LuaApplication::broadcastEvent. Both threads are using the same lua_State* L pointer.
Pictures of the stack traces are below. I have 2 ideas currently. First, this is a problem I introduced with my changes to BhWax. Second, we have 2 native threads modifying the same lua_State pointer and crashing. I am leaning towards the second idea because as far as I can tell, Lua states are NOT thread safe.
If anyone has any ideas I would love to hear it. Thanks in advance.
Thread 1 0 luau_execute 1 luau_execute 2 luaD_call 3 ::lua_call(lua_State *, int, int) 4 eventClosureWithData 5 luau_precall 6 luaD_call 7 ::lua_call(lua_State *, int, int) 8 CppLuaBridge::luaEvent 9 EventDispatcher::dispatchEvent 10 EventDispatcherBinder::dispatchEvent 11 luau_execute 12 luau_execute 13 luaD_call 14 ::lua_call(lua_State *, int, int) 15 luaBlockARM64ReturnBufferWithParameters 16 __lua_LongLong_block_1q block_inv... 17 [PFGeoPoint geoPointForCurrentLocationWithError:] 18 -[PFLocationManager locationManag... 19 __lldb_unnamed_symbol1491 29 UIApplicationMain 30 main 31 start_sim 32 start |
Thread 21 0 ::lua_remove(lua_State *, int) 1 ::lua_pcall_traceback(lua_State *, int, ... 2 LuaApplication::broadcastEvent(event, status) 3 ApplicationManager::surfaceChanged 4 -[EAGLView createFramebuffer] 5 -[EAGLView setFramebuffer] 6 ApplicationManager::renderLoop 7 ApplicationManager:renderLoop_s 8 __NSThread__start_) 10 thread_start |