Commit 3575b51
Fix race condition in script reload causing null pointer crash
When pressing 'apply' to reload a script, the code had a critical
thread-safety issue: multiple threads were executing Lua operations
on the same lua_State concurrently without proper synchronization.
The race condition occurred because:
1. UI thread would load/compile new script WITHOUT holding the lock
2. Audio thread could be running script->process() at the same time
3. Both threads manipulate the same Lua stack -> corruption
4. This caused DSPScriptPosition userdata to become invalid
5. Accessing position methods (bar(), beat(), etc.) would crash
with null pointer dereference
The fix moves the ScopedLock acquisition to the very beginning of
loadScript(), ensuring ALL Lua operations are serialized:
- Script loading and compilation
- DSPScript construction
- Script preparation
- Pointer swap
- Old script cleanup (release, cleanup, destructor)
This prevents any concurrent Lua state access. The tradeoff is a
brief audio dropout during script reload, which is acceptable for
this operation.
Fixes crash: Access violation reading location 0x0000000000000000
in DSPScriptPosition::_bar() and DSPScriptPosition::_beat()
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>1 parent dbbecc6 commit 3575b51
1 file changed
+9
-11
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
123 | 123 | | |
124 | 124 | | |
125 | 125 | | |
| 126 | + | |
| 127 | + | |
126 | 128 | | |
127 | 129 | | |
128 | 130 | | |
| |||
133 | 135 | | |
134 | 136 | | |
135 | 137 | | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
| 141 | + | |
136 | 142 | | |
137 | | - | |
138 | | - | |
139 | | - | |
140 | | - | |
141 | | - | |
142 | | - | |
143 | | - | |
144 | | - | |
145 | | - | |
146 | | - | |
147 | | - | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
148 | 146 | | |
149 | 147 | | |
150 | 148 | | |
| |||
0 commit comments