SIGSEGV in SoundTouch 1.9.2

[Uwe Klotz]

OS: Fedora 23 x86_64
Lib: soundtouch-1.9.2-3.fc23.x86_64

Branch: master (2.1.0-alpha-pre x64)
Key Lock enabled
Pitch at 0.00
  - not moved during the whole session (AutoDJ background music @home)
File plays fine after restart
  - same results
  - waveform generation is skipped now

Warning [AnalyzerQueue 1]: Recoverable MP3 frame decoding error: lost synchronization
Debug [AnalyzerQueue 1]: Waveform generation for track 92614 done 6 s
Debug [AnalyzerQueue 1]: ReplayGain 2.0 (libebur128) result is -2.78099 dB for "/home/uk/Music/Collection/nico/chelsea girl/01-02 nico these days.mp3"
Debug [AnalyzerQueue 1]: Beat Calculation complete
Debug [AnalyzerQueue 1]: Key Detection complete
Debug [AnalyzerQueue 1]: Key Histogram
Debug [AnalyzerQueue 1]: 6 : "F" 7.93267e+06
Debug [AnalyzerQueue 1]: 11 : "B♭" 1.47456e+06

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffee22d2700 (LWP 16845)]
0x00007ffff7891e90 in soundtouch::TDStretch::overlapStereo(float*, float const*) const () from /usr/lib64/libSoundTouch.so.1
(gdb) bt
#0 0x00007ffff7891e90 in soundtouch::TDStretch::overlapStereo(float*, float const*) const () at /usr/lib64/libSoundTouch.so.1
#1 0x00007ffff7893037 in soundtouch::TDStretch::processSamples() ()
    at /usr/lib64/libSoundTouch.so.1
#2 0x00007ffff7891490 in soundtouch::SoundTouch::putSamples(float const*, unsigned int) () at /usr/lib64/libSoundTouch.so.1
#3 0x00000000007cfc82 in EngineBufferScaleST::getScaled(float*, int) (this=0x20a9d00, pOutput=<optimized out>, buf_size=2048)
    at src/engine/enginebufferscalest.cpp:164
#4 0x00000000007cba11 in EngineBuffer::process(float*, int) (this=0x1fa1be0, pOutput=0x7fffc8792010, iBufferSize=2048) at src/engine/enginebuffer.cpp:983
#5 0x00000000007d1310 in EngineDeck::process(float*, int) (this=0x1f759d0, pOut=0x7fffc8792010, iBufferSize=2048) at src/engine/enginedeck.cpp:98
#6 0x00000000007dff4e in EngineMaster::processChannels(int) (this=this@entry=0x14fe100, iBufferSize=iBufferSize@entry=2048) at src/engine/enginemaster.cpp:318
#7 0x00000000007e8b50 in EngineMaster::process(int) (this=0x14fe100, iBufferSize=iBufferSize@entry=2048) at src/engine/enginemaster.cpp:350
#8 0x0000000000b47d5b in SoundManager::onDeviceOutputCallback(unsigned int) (this=<optimized out>, iFramesPerBuffer=iFramesPerBuffer@entry=1024)
    at src/soundio/soundmanager.cpp:548
#9 0x0000000000b44a36 in SoundDevicePortAudio::callbackProcessClkRef(unsigned int, float*, float const*, PaStreamCallbackTimeInfo const*, unsigned long) (this=0x1e337c0, framesPerBuffer=1024, out=0x4de4f2a0, in=<optimized out>, timeInfo=<o---Type <return> to continue, or q <return> to quit---
ptimized out>, statusFlags=<optimized out>)
    at src/soundio/sounddeviceportaudio.cpp:949
#10 0x00007ffff7459454 in AdaptingOutputOnlyProcess ()
    at /usr/lib64/libportaudio.so.2
#11 0x00007ffff745aded in PaUtil_EndBufferProcessing ()
    at /usr/lib64/libportaudio.so.2
#12 0x00007ffff746391b in CallbackThreadFunc () at /usr/lib64/libportaudio.so.2
#13 0x00007ffff1d1e60a in start_thread () at /usr/lib64/libpthread.so.0
#14 0x00007fffeeeb5a4d in clone () at /usr/lib64/libc.so.6

[Owen Williams (ywwg)]

in the past we've had crashes when either soundtouch or rubberband were fed "crazy" rates, like 0 or 10000000000. So this might be a case where we aren't successfully detecting an invalid rate.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Before the crash it played for 2 hours without any issues so I don't think this is caused by some weird parameter. Looks more like a memory corruption issue.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Might be fixed:
https://github.com/mixxxdj/mixxx/commit/af99a26bdd5ddfa4217b06d552cfd5755740908d

[Uwe Klotz (uklotzde-deactivatedaccount)]

@rryan: Should we change the status to "Fix Committed"? I think your commit fixes this bug.

[RJ Skerry-Ryan (rryan)]

Uwe -- I could never reproduce the segfault so I'm not sure if I fixed it. But maybe we can declare it fixed and reopen if someone sees it again.

I also enabled asan in our Travis builds so we should notice memory safety bugs like this in the future at PR-time.

[RJ Skerry-Ryan (rryan)]

(assuming the tests exercise the code path :X)

[RJ Skerry-Ryan (rryan)]

The overflow was only at bootup though -- but maybe it trashed some internal soundtouch or engine state that caused your segfault.

[Waylon Robertson (wrobertson1981)]

Thread 11 "mixxx" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff503dd700 (LWP 8345)]
0x00007ffff7892140 in soundtouch::TDStretch::overlapStereo(float, float const) const () from /usr/lib/x86_64-linux-gnu/libSoundTouch.so.1

Crash while using the library-redesign branch, 1 1/2 hours into a set. Possible regression.

How do I trigger this problem, reliably?

[Daniel Schürmann (daschuer)]

Could you remember what your rate slider and keylock state was just before the crash?

[Daniel Schürmann (daschuer)]

A similar bug is fixed here:
https://sourceforge.net/p/soundtouch/code/236
And released with Soundtouch 2.0
On which version are you?

[Waylon Robertson (wrobertson1981)]

uhh... 1.9.2.2-2, the latest is 1.9.2-3... there is no soundtouch 2 released for ubuntu as far as i know?

[Waylon Robertson (wrobertson1981)]

Switching to Rubberband to play it safe.

[Daniel Schürmann (daschuer)]

So we need to provide Soundtouch ourselves for Ubuntu as well.
Or put Soundtouch into our ppa. I

[Daniel Schürmann (daschuer)]

The upstream bug is tracked here:
https://sourceforge.net/p/soundtouch/bugs/4/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Be (be.ing)]

> So we need to provide Soundtouch ourselves for Ubuntu as well.
Or put Soundtouch into our ppa.

IMO that should only be done in extreme circumstances. It would be better to work with Ubuntu to update their Soundtouch package. Fedora 28 is shipping Soundtouch 2.0. Arch is as well.

[Daniel Schürmann (daschuer)]

I have already assigned this bug to them. What else can we do?

[Be (be.ing)]

According to https://launchpad.net/ubuntu/+source/soundtouch the package is maintained by the Debian Multimedia Team, so I guess contact them to notify them of the urgency of updating the Soundtouch package. I do not know if they receive notifications from Launchpad automatically, so I sent an email to <email address hidden>

[Uwe Klotz (uklotzde-deactivatedaccount)]

Why not simply increasing the minimum required version from 1.8.0 to 2.0.0?

[Waylon Robertson (wrobertson1981)]

Huh? and break the easy installation of Mixxx until Debian/ubuntu update the package?

[Daniel Schürmann (daschuer)]

> Why not simply increasing the minimum required version from 1.8.0 to 2.0.0?

Yes, that is the way to go here. Trusty for example has Soundtouch 1.7 so we build it with our own static library anyway. If Ubuntu has 2.0.0 one day, it will uses the system provided version again.

[Sebastian Ramacher (s-ramacher)]

2.0.0 is now available in Ubuntu. FWIW, the Debian Multimedia Team does not receive notifications from Launchpad. So if you require actions from us, please file bugs in the Debian bug tracker or contact the mailing list.

[Daniel Schürmann (daschuer)]

We now use our own sounddouch 2.0 if the distro provided version is lower.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8534