Mixxx crashes at scratching -> floating point exception

Bug #1263233 reported by Freier Radikaler on 2013-12-20
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Critical
RJ Skerry-Ryan
Ubuntu
Undecided
Unassigned

Bug Description

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

affects: mixxx → ubuntu
Changed in ubuntu:
status: New → Confirmed
Changed in mixxx:
status: New → Confirmed
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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

Changed in ubuntu:
status: Confirmed → Invalid
Changed in mixxx:
milestone: none → 1.12.0
importance: Undecided → Critical
Revision history for this message
jus (jus) wrote :

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

Revision history for this message
Freier Radikaler (freier-radikaler) wrote :

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

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

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

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1263233] Re: Mixxx crashes at scratching -> floating point exception

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

Revision history for this message
jus (jus) wrote :

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

Revision history for this message
Freier Radikaler (freier-radikaler) wrote :

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

Revision history for this message
Freier Radikaler (freier-radikaler) wrote :

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?

Revision history for this message
Owen Williams (ywwg) wrote :

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

Revision history for this message
Owen Williams (ywwg) wrote :

fixed in 16f4b92d4f752f65ca55294af6fb3c69450c0da9

Revision history for this message
Owen Williams (ywwg) wrote :

herp derp wrong bug, not fixed

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

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

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

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.

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

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.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :
Changed in mixxx:
assignee: nobody → RJ Ryan (rryan)
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

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

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

Revision history for this message
Freier Radikaler (freier-radikaler) wrote :

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!

RJ Skerry-Ryan (rryan) on 2013-12-25
Changed in mixxx:
status: Confirmed → Fix Committed
RJ Skerry-Ryan (rryan) on 2015-12-30
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments