SIGSEGV in SoundTouch 1.9.2

Bug #1577042 reported by Uwe Klotz
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mixxx
Critical
Unassigned
soundtouch (Ubuntu)
Undecided
Unassigned

Bug Description

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

Uwe Klotz (uklotzde)
description: updated
description: updated
Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
Uwe Klotz (uklotzde) wrote :

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.

description: updated
Revision history for this message
Uwe Klotz (uklotzde) wrote :
Revision history for this message
Uwe Klotz (uklotzde) wrote :

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

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

(assuming the tests exercise the code path :X)

Changed in mixxx:
status: New → Fix Committed
milestone: none → 2.1.0
importance: Undecided → Critical
assignee: nobody → RJ Ryan (rryan)
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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

Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Waylon Robertson (wrobertson1981) wrote :

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?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Revision history for this message
Waylon Robertson (wrobertson1981) wrote :

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?

Revision history for this message
Waylon Robertson (wrobertson1981) wrote :

Switching to Rubberband to play it safe.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

summary: - SIGSEGV in SoundTouch
+ SIGSEGV in SoundTouch 1.9.2
Changed in mixxx:
status: Fix Released → Confirmed
assignee: RJ Skerry-Ryan (rryan) → nobody
milestone: 2.1.0 → 2.2.0
milestone: 2.2.0 → 2.1.2
Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in soundtouch (Ubuntu):
status: New → Confirmed
affects: ubuntu → soundtouch (Ubuntu)
Changed in soundtouch (Ubuntu):
status: New → Confirmed
Revision history for this message
Be (be.ing) wrote :

> 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.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Revision history for this message
Be (be.ing) wrote :

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>

Revision history for this message
Uwe Klotz (uklotzde) wrote :

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

Revision history for this message
Waylon Robertson (wrobertson1981) wrote :

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

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> 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.

Revision history for this message
Sebastian Ramacher (s-ramacher) wrote :

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.

Changed in soundtouch (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Daniel Schürmann (daschuer) wrote :

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

Changed in mixxx:
milestone: 2.1.2 → 2.1.1
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers