Mixxx crashes at scratching -> floating point exception

[Freier Radikaler]

The current git version of mixxx (commit 18b314a6221c0629f5807552e0e03488be573e59) crashes if a track is loaded, key lock is on and then scratching a few times while deck is or isn't playing. The terminal says floating point exception. The bug is good reproduceable. Specially if you use a midi controller like Reloop Terminal Mix 4.

This bug should be relatively new because this kind of behaviour i haven't seen before. So some of the last commits should have triggered it...

[RJ Skerry-Ryan (rryan)]

Thanks for the report -- there are a variety of things that could have caused this. I can't reproduce this, though.

Could you please get a backtrace?
http://mixxx.org/wiki/doku.php/creating_backtraces

[jus (jus)]

Crash confirmed, exactly as described, even if Pitch is at +-0.00%.
See backtrace

This line is new too:
Debug [Main]: ERROR: InternalClock beat length should never be less than zero

[Freier Radikaler (freier-radikaler)]

Here are the last lines of my gdb output after the bug occures:

Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x3F"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x3E"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x3F"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x42"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
Debug [Controller]: "MIDI status 0xB0 (ch 1, opcode 0xB), ctrl 0x28, val 0x41"
[New LWP 9875]

Program received signal SIGFPE, Arithmetic exception.
[Switching to LWP 9875]
0x00007ffff302d7dd in RubberBand::RubberBandStretcher::Impl::calculateIncrements(unsigned long&, unsigned long&, bool&) () from /usr/lib64/librubberband.so.2

As "jus" described it, it isn't necessaray to pitch. Keylock on and scratching is enough. It seems to be a problem how calculateIncrements(unsigned long&, unsigned long&, bool&) is called. I assume that the unsigned long values are called with a float or someting!? I'm not that deeply into the code...
The bug is current in r3802 also...

[RJ Skerry-Ryan (rryan)]

What version of librubberband are you using? I am on 1.8.1 and cannot reproduce with the steps you included.

[RJ Skerry-Ryan (rryan)]

(Mixxx prints its rubberband version at the start of its log)
On Dec 21, 2013 1:55 PM, "RJ Ryan" <email address hidden> wrote:

> What version of librubberband are you using? I am on 1.8.1 and cannot
> reproduce with the steps you included.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1263233
>
> Title:
> Mixxx crashes at scratching -> floating point exception
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1263233/+subscriptions
>

[jus (jus)]

@RJ
I'm using Rubberband 1.8.1 on OSX (See backtrace), and it crashes too. You dont even need a controller to make it happen. Just load a track to a deck, do not start the playback, just do a right-click scratch on the waveform display.

Instantly crashes with "Floating point exception: 8"

[Freier Radikaler (freier-radikaler)]

eix rubberband
[I] media-libs/rubberband
     Available versions: 1.7.0 1.8.1 {static-libs}
     Installed versions: 1.8.1(13:53:19 28.07.2013)(-static-libs)
     Homepage: http://www.breakfastquay.com/rubberband/
     Description: An audio time-stretching and pitch-shifting library and utility program

I used the same version as "jus".

[Freier Radikaler (freier-radikaler)]

My operating system is Sabayon Linux (Gentoo based) with a 3.9.0 kernel and rubberband 1.8.1, qtcore 4.8.5, gdb 7.5.1, scons 2.3.0, git 1.8.3.3, gcc 4.6.4 and python 2.6.8-r1 & 3.3.2-r2.

Do you need any further informations?

[Owen Williams (ywwg)]

what sound settings are you using, ie sample rate and latency?

[Owen Williams (ywwg)]

fixed in 16f4b92d4f752f65ca55294af6fb3c69450c0da9

[Owen Williams (ywwg)]

herp derp wrong bug, not fixed

[RJ Skerry-Ryan (rryan)]

Ah, right click scratch! I still see no crash but I see this warning from rubberband. Do you see it?

WARNING: reconfigure(): window allocation (size 8192) required in RT mode

[RJ Skerry-Ryan (rryan)]

Ah! I am using rubberband tip which is 3 commits past 1.8.1. This seems to be fixed in tip. I downgraded to the 1.8.1 tag and it crashed right away. I'll look for a workaround.

[RJ Skerry-Ryan (rryan)]

Oops, it's not actually fixed in RB tip. I just didn't know how to reproduce it fully.

1) Load track to deck.
2) Don't play / move yet.
3) Enable keylock.
4) Right click scratch forward.

It looks like speeds of less than 0.00390625 (1/256) crash librubberband because it causes the input-increment variable to be 0 and there are a bunch of places in librubberband that code divided by the input increment.

We had a similar MIN_SEEK_SPEED in SoundTouch so I could just add that workaround in. I'll also report this upstream.

[RJ Skerry-Ryan (rryan)]

Bug filed upstream:
https://bitbucket.org/breakfastquay/rubberband/issue/4/sigfpe-zero-division-with-high-time-ratios

[RJ Skerry-Ryan (rryan)]

Workaround added in
https://github.com/mixxxdj/mixxx/commit/1cbbf166802453fa0c670aa50380520f17b1104c

If you can still get it to crash, please let me know.

[Freier Radikaler (freier-radikaler)]

I just testet r3820 hardly which contains your fix. I can't get it to crash. So the fix seems to work.
Thanks for patching!

[Swiftb0y (swiftb0y)]

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