MWEngine
MWEngine copied to clipboard
igorski
Thread issue maybe?
I'm using handleNotification() in your StateObserver class (just copied from your example) to update things in realtime and create automations (this includes modifying things in the engine, ex. changing a parameter on an fx step 3-6). When just calling the relevant objects I get occasional null pointer dereference crashes. Calling them from the UI-thread is way more stable. I'm not good at threads, I guess I just vaguely get the concept, but it seems engine updates should execute in whatever thread the engine used to call them to avoid conflicts like this? Or does it get weird C -> Java? Or am I completely wrong here and just need to write better applications =)? (that last happy face does not mean I don't see it as an option, as I said I don't know threads).
The crash I'm getting is this one and I'm somewhat able to reproduce it when the sequencer goes from last step -> 0:
2022-06-16 11:33:26.928 32383-32383/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.0.0/OSR1.170901.043/4456315:user/release-keys'
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: Revision: '0'
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: ABI: 'x86'
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: pid: 32329, tid: 32356, name: Thread-2 >>> com.kiefer.llppdrums <<<
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: Cause: null pointer dereference
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: eax 91b7ea00 ebx 928f48a8 ecx ad8595f0 edx 924ff330
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: esi 000178bf edi 00017610
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: xcs 00000073 xds 0000007b xes 0000007b xfs 0000003b xss 0000007b
2022-06-16 11:33:26.929 32383-32383/? A/DEBUG: eip 00000000 ebp 924ff358 esp 924ff2cc flags 00010286
2022-06-16 11:33:26.933 32383-32383/? A/DEBUG: backtrace:
2022-06-16 11:33:26.933 32383-32383/? A/DEBUG: #00 pc 00000000
In this case nothing except for some UI-elements is modified through handleNotification(), but it's much less frequent when calling from the UI-thread so it still feels like it has something to do with that.
No idea if this is the engine or if this info is relevant to you. I've had this for a long time and made an issue before where I blamed muting, which was wrong. I can upload the tombstone if you want it.
In the crash I was able to reprodice I've deleted steps (which means deleted events) while the engine was paused (and randomized other things) and the crash happens when the sequencer goes from last step -> 0.
Just to be clear: I have no idea if this is thread related, I just noticed less crashes in the UI-thread.
When deleteing tracks while the engine is running I'm getting the exact same crash exept for step 0 in firebase that says "missing". All other steps are identical.
A little note here: deleteing tracks while the engine is running does not mean deleting events. I've had trouble deleting events with the engine running before, so right now I store them and delete all when the engine is paused. Same goes for fxs and instruments. This is an old fix and I don't know if it's needed anymore, I will investigate this soon.
So I had some time to look into this.
Debouncing on the UI thread may work as as the handler will not be executed synchronously with the sequencer, which reduces risk of concurrent operations on removed items.
So just to be clear : the action you re performing is removing events from the sequencer while it is running right (using removeFromSequencer) ? (Note: this should totally work, so this is a definitive bug if this is the case). If you are doing other things maybe you can post a snippet of the changes you are executing ? Judging from the stack trace I have assumed it's related to event removal though.
If you push the latest version of the repository and rebuild the library, is the issue addressed ?
Can't assemble the latest version with #define RECORD_DEVICE_INPUT and #define RECORD_TO_DISK commented away. utilities/diskwriter.h is never included and still called further down. Will try with them enabled but thaught you should know.
Tried for a while with the version I had before the latest and had zero crashes. I could pretty reliably recreate it before, atleast once every 10th try or so, so might be that it was solved allready.
Sorry for the vagueness, been away for three weeks.
utilities/diskwriter.h is never included and still called further down in audioengine.cpp!!
Ah sorry that's embarrassing 🙈
A recent improvement to the recording API left this lingering and I didn't check the impact in the case RECORD_DEVICE_INPUT|RECORD_TO_DISK was disabled in global.h. I have pushed a change that removed the old import guard (DiskWriter will then be included - as it was before, but in a different file as it depends on the same imports as file import/WaveReader - but the recording code will remain dormant during render, as before).
In the crash I could reproduce I had removed/added events to the engine before starting the sequencer. I think the events are irrelevant. The updates are simple, like increasing the delay time on certain steps, using handleNotification(). The crash always occured at step 0 (or maybe the last step) but nothing special in regards to the engine is happening there. Blaming it on threads was just a thaught I had.