Newest Scriptnode Commits Causing Frequent Crashes in Exported App
-
Hey all,
I just merged my HISE repo with some of the newest scriptnode commits and immediately started getting crashes when I export a standalone build and play one of my presets. I'm pretty sure it's related to this big scriptnode merge.
@Christoph-Hart any thoughts?
Here's the symbolicated crash report:
Process: CUBE [57943] Path: /Volumes/VOLUME/*/CUBE.app/Contents/MacOS/CUBE Identifier: com.lunacyaudio.cube Version: 0.9.1 (0.9.1) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: CUBE [57943] User ID: 502 Date/Time: 2021-03-13 14:55:14.686 -0800 OS Version: Mac OS X 10.13.6 (17G66) Report Version: 12 Anonymous UUID: 17C59BB8-3A7A-3916-1D3C-0AA0A4200CB9 Time Awake Since Boot: 860000 seconds System Integrity Protection: enabled Crashed Thread: 11 com.apple.audio.IOThread.client Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000011b3fa000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] VM Regions Near 0x11b3fa000: MALLOC_LARGE 000000011b15f000-000000011b3fa000 [ 2668K] rw-/rwx SM=PRV --> MALLOC_LARGE 000000011b3fb000-000000011b42e000 [ 204K] rw-/rwx SM=PRV Thread 11 Crashed:: com.apple.audio.IOThread.client 0 com.lunacyaudio.cube 0x000000010c7853db hise::StreamingSamplerVoice::renderNextBlock(juce::AudioBuffer<float>&, int, int) + 2571 (StreamingSamplerVoice.cpp:669) 1 com.lunacyaudio.cube 0x000000010c2d4575 hise::ModulatorSamplerVoice::calculateBlock(int, int) + 837 (ModulatorSynth.h:860) 2 com.lunacyaudio.cube 0x000000010bffa77a hise::ModulatorSynthVoice::renderNextBlock(juce::AudioBuffer<float>&, int, int) + 58 (juce_SmoothedValue.h:65) 3 com.lunacyaudio.cube 0x000000010bff58e3 hise::ModulatorSynth::renderVoice(int, int) + 595 (ModulatorSynth.cpp:485) 4 com.lunacyaudio.cube 0x000000010bfee90a hise::ModulatorSynth::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 570 (ModulatorSynth.cpp:398) 5 com.lunacyaudio.cube 0x000000010bff836f hise::ModulatorSynthChain::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 431 (ModulatorSynthChain.cpp:247) 6 com.lunacyaudio.cube 0x000000010bff836f hise::ModulatorSynthChain::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 431 (ModulatorSynthChain.cpp:247) 7 com.lunacyaudio.cube 0x000000010bfa590e hise::MainController::processBlockCommon(juce::AudioBuffer<float>&, juce::MidiBuffer&) + 11006 (MainController.cpp:992) 8 com.lunacyaudio.cube 0x000000010c95a0e8 juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) + 1912 (juce_AudioProcessorPlayer.cpp:175) 9 com.lunacyaudio.cube 0x000000010c8e705c juce::AudioDeviceManager::CallbackHandler::audioDeviceIOCallback(float const**, int, float**, int, int) + 908 (juce_AudioSampleBuffer.h:315) 10 com.lunacyaudio.cube 0x000000010c8e3f8d juce::CoreAudioClasses::CoreAudioInternal::audioIOProc(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 301 (juce_mac_CoreAudio.cpp:782) 11 com.apple.audio.CoreAudio 0x00007fff34d1c825 HALC_ProxyIOContext::IOWorkLoop() + 5021 12 com.apple.audio.CoreAudio 0x00007fff34d1b2bc HALC_ProxyIOContext::IOThreadEntry(void*) + 128 13 com.apple.audio.CoreAudio 0x00007fff34d1affe HALB_IOThread::Entry(void*) + 72 14 libsystem_pthread.dylib 0x00007fff5d4db661 _pthread_body + 340 15 libsystem_pthread.dylib 0x00007fff5d4db50d _pthread_start + 377 16 libsystem_pthread.dylib 0x00007fff5d4dabf9 thread_start + 13 -
I guess we'll find out on Monday. I have removed the truncation of the max sampler up-pitching, and this might cause some issues with heavily repitched sample material, but it shouldn't be hard to figure it out if it crashes consistently.
-
@Christoph-Hart Sounds good! This is definitely a new one, but it should be pretty easy to sniff out. I think it's directly related to heavily pitched samples like you said. Will do some more investigating.
-
@Christoph-Hart said in Newest Scriptnode Commits Causing Frequent Crashes in Exported App:
I guess we'll find out on Monday. I have removed the truncation of the max sampler up-pitching, and this might cause some issues with heavily repitched sample material, but it shouldn't be hard to figure it out if it crashes consistently.
As this been fixed? I do have problems with one of my sample maps with heavily repitched sample.
-
@marcLab I think mostly, though I still can force crashes with a glide script if I stretch a sample more than 4 or 5 octaves.
-
Yes that new way of handling highly repitched samples doesn't factor in dynamic pitch ratios (it just looks whether the samplemap pitches the sample up more than the
MAX_SAMPLER_PITCH_RATIOand then loads that particular sample entirely. I might reintroduce the old behaviour (where the pitch ratio was capped) for the cases where a dynamic ratio exceeds that value (which right now is undefined and results in a crash).
