Mixxx crashes with std::bad_alloc with scratch ramping enabled on Ubuntu Studio 21
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Released
|
Critical
|
Unassigned |
Bug Description
Related topic on Zulip: https:/
I can reliably trigger a crash on Mixxx 2.3.1 and Ubuntu Studio 21:
1. Start Mixxx
2. Load and play two tracks
3. Touch and rotate both jogwheels at the same time. This is the first time the jogwheels are touched since Mixxx was started.
First the UI freezes, but audio continues. Then audio drops out after ~30 seconds. Then the whole system freezes for ~2 minutes until it recovers itself. Mixxx has to be restarted.
I can prevent this bug when not using ramping in scratchEnable() and scratchDisable() in my controller mapping. I did some debugging and found that isScratching() returns true even after scratchDisable(). This can be prevented with ramp = false, but I am not sure how this is related.
My mapping can be found here (ramp is set to false, to prevent crashes): https:/
I have multiple backtraces when this happened (some contain mapping debug logs).
summary: |
- Mixxx freezes and window manager crashes + Mixxx crashes with std::bad_alloc on Ubuntu Studio 21 |
Changed in mixxx: | |
importance: | Undecided → Critical |
Changed in mixxx: | |
status: | Confirmed → Fix Committed |
summary: |
- Mixxx crashes with std::bad_alloc on Ubuntu Studio 21 + Mixxx crashes with std::bad_alloc with scratch ramping enabled on Ubuntu + Studio 21 |
Changed in mixxx: | |
status: | Fix Committed → Fix Released |
engine. isScratching( )/scratchEnable ()/scratchDisab le() with ramping enabled is used in a similar way in the mapping for the MC6000MK2 and never caused any issues. I am not able to reproduce those crashes.
Without the ability to reproduce the issues on different hard- and software it will be unlikely that they ever get fixed.