Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when using Sink->Lofi preset / Flutter Depth [BUG] #302

Closed
gedobbles opened this issue Feb 3, 2023 · 5 comments
Closed

Crash when using Sink->Lofi preset / Flutter Depth [BUG] #302

gedobbles opened this issue Feb 3, 2023 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@gedobbles
Copy link

After switching to the Sink->LoFi Plugin the plugin crashes in the next few seconds both in Ardour7 and standalone.
The left channel goes silent shortly before the crash.
The crash also happens if you use the default preset and crank Flutter Depth up a bit.

Steps to reproduce the behavior:

  • Open the plugin, (connect to audio source if standalone)
  • switch to Sink->LoFi
  • wait a few seconds

Expected behavior
It should continue to work.

Desktop (please complete the following information):

  • OS: Ubuntu 22.04.1 LTS
  • DAW Ardour7, standalone
  • Version 2.9.0 - 2.11.2
[----------------------------------registers-----------------------------------]
RAX: 0x560a6f0acba0 --> 0x0 
RBX: 0x0 
RCX: 0x200001 
RDX: 0x26480 
RSI: 0xffffffff80026481 
RDI: 0xffffffff80026484 
RBP: 0x560a6eec17b0 --> 0x40a8720640a8c9ae 
RSP: 0x7fe4ad6ac830 --> 0x0 
RIP: 0x560a6dff6299 (<_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5545>:       mulss  xmm2,DWORD PTR [r10+rdi*4])
R8 : 0xffffffff80026483 
R9 : 0xffffffff80026482 
R10: 0x560a6f21fe60 --> 0x0 
R11: 0x560a6eef7800 --> 0x2661800026481 
R12: 0x560a6f007640 --> 0x3f678e7c3f6fb31c 
R13: 0x560a6eef7a90 --> 0x3fe8b77e3feb6e5e 
R14: 0x560a6ecb7590 --> 0x560a6e2471a0 --> 0x560a6dfd25d0 (<_ZN27ChowtapeModelAudioProcessorD2Ev>:      endbr64)
R15: 0x197
EFLAGS: 0x10a12 (carry parity ADJUST zero sign trap INTERRUPT direction OVERFLOW)
[-------------------------------------code-------------------------------------]
   0x560a6dff6289 <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5529>:  mulss  xmm3,xmm5
   0x560a6dff628d <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5533>:  mulss  xmm2,xmm1
   0x560a6dff6291 <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5537>:  divss  xmm2,DWORD PTR [rip+0x1f4cf]        # 0x560a6e015768
=> 0x560a6dff6299 <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5545>:  mulss  xmm2,DWORD PTR [r10+rdi*4]
   0x560a6dff629f <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5551>:  mulss  xmm1,xmm5
   0x560a6dff62a3 <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5555>:  mulss  xmm0,xmm7
   0x560a6dff62a7 <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5559>:  mulss  xmm3,xmm7
   0x560a6dff62ab <_ZN27ChowtapeModelAudioProcessor17processAudioBlockERN4juce11AudioBufferIfEE+5563>:  mulss  xmm0,DWORD PTR [r10+r9*4]
[------------------------------------stack-------------------------------------]
0000| 0x7fe4ad6ac830 --> 0x0 
0008| 0x7fe4ad6ac838 --> 0x3f80000000000000 
0016| 0x7fe4ad6ac840 --> 0x560a6ef4ff60 --> 0x3e49c62f3e4d3c4f 
0024| 0x7fe4ad6ac848 --> 0x0 
0032| 0x7fe4ad6ac850 --> 0x0 
0040| 0x7fe4ad6ac858 --> 0x7fe4ad6aca70 --> 0x20000000002 
0048| 0x7fe4ad6ac860 --> 0x0 
0056| 0x7fe4ad6ac868 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x0000560a6dff6299 in ChowtapeModelAudioProcessor::processAudioBlock(juce::AudioBuffer<float>&) ()
gdb-peda$ where
#0  0x0000560a6dff6299 in ChowtapeModelAudioProcessor::processAudioBlock(juce::AudioBuffer<float>&) ()
#1  0x0000560a6dfbdad3 in chowdsp::PluginBase<ChowtapeModelAudioProcessor>::processBlock(juce::AudioBuffer<float>&, juce::MidiBuffer&) ()
#2  0x0000560a6df76fc3 in juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) ()
#3  0x0000560a6e008c17 in juce::StandalonePluginHolder::CallbackMaxSizeEnforcer::audioDeviceIOCallback(float const**, int, float**, int, int) ()
#4  0x0000560a6ddd1d6f in juce::AudioDeviceManager::CallbackHandler::audioDeviceIOCallback(float const**, int, float**, int, int) ()
#5  0x0000560a6dddbfef in juce::(anonymous namespace)::ALSAThread::run() ()
#6  0x0000560a6ddef91b in juce::threadEntryProc(void*) [clone .lto_priv.0] ()
#7  0x00007fe4af907b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#8  0x00007fe4af999a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
@gedobbles gedobbles added the bug Something isn't working label Feb 3, 2023
@jatinchowdhury18
Copy link
Owner

Hello! Thanks for sharing the bug report. Unfortunately I haven't been able to re-create the crash on any of my systems, although I also don't currently have an Ardour setup to test with.

There's a few other bits of information that would be helpful for the debugging process:

  • Would it be possible to share the sample rate and block size being used by the plugin when the crash occurs? I would also be curious to know if the crash still happens at some different sample rates.
  • When triggering the crash from the default preset, is there a typical value (or threshold) of the flutter depth that seems to cause the crash?
  • Is it possible to trigger the crash from the "Wow" processor rather than flutter?
  • Finally, if you're comfortable with building the plugin from source, it might be possible to get a more detailed stack trace, or run the plugin inside a debugger that could provide more clues.

Thanks!

@gedobbles
Copy link
Author

My tests show that the crash happens only at a samplerate of 192kHz, also with the Wow processor.
I don't have time to generate more reports now, but that information should enable you to reproduce it.

@jatinchowdhury18
Copy link
Owner

Okay, I was able to re-create the crash running at the higher sample rate. I've got a fix merged (see #303), which should be in the nightly builds this evening.

@gedobbles
Copy link
Author

I just tested with the build from develop, it seems that the issue is fixed, no problems so far standalone and in Ardour.

@jatinchowdhury18
Copy link
Owner

Okay great! Then I'll close this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants