Mixxx crashes at scratching -> floating point exception

[mixxxbot]

Reported by: freier-radikaler
Date: 2013-12-20T21:34:49Z
Status: Fix Released
Importance: Critical
Launchpad Issue: lp1263233
Attachments: backtrace.txt

---

The current git version of mixxx (commit 18b314a) 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...

[mixxxbot]

Commented by: rryan
Date: 2013-12-20T22:01:56Z

---

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

[mixxxbot]

Commented by: esbrandt
Date: 2013-12-21T08:47:17Z
Attachments: backtrace.txt

---

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 

[mixxxbot]

Commented by: freier-radikaler
Date: 2013-12-21T16:15:46Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2013-12-21T18:49:03Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2013-12-21T19:26:19Z

---

(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

[mixxxbot]

Commented by: esbrandt
Date: 2013-12-22T07:06:11Z

---

@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"

[mixxxbot]

Commented by: freier-radikaler
Date: 2013-12-22T14:07:27Z

---

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

[mixxxbot]

Commented by: freier-radikaler
Date: 2013-12-22T14:33:07Z

---

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?

[mixxxbot]

Commented by: ywwg
Date: 2013-12-22T15:35:15Z

---

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

[mixxxbot]

Commented by: ywwg
Date: 2013-12-22T15:38:20Z

---

fixed in 16f4b92

[mixxxbot]

Commented by: ywwg
Date: 2013-12-22T15:38:39Z

---

herp derp wrong bug, not fixed

[mixxxbot]

Commented by: rryan
Date: 2013-12-22T17:04:04Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2013-12-22T17:49:43Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2013-12-22T21:51:37Z

---

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.

[mixxxbot]

Commented by: rryan
Date: 2013-12-22T22:31:56Z

---

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

[mixxxbot]

Commented by: rryan
Date: 2013-12-23T09:01:13Z

---

Workaround added in
1cbbf16

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

[mixxxbot]

Commented by: freier-radikaler
Date: 2013-12-24T21:43:58Z

---

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!

[mixxxbot]

Issue closed with status Fix Released.