Crash when one deck on hot cue loop and loading to another deck

[RadioDM]

Bug Description

When one deck is on an active hotcue loop (loop saved as a hotcue point) and loading track to the other deck, Mixxx crash. It does not crash if track is on normal loop, or in any other instance

It happened on 2.4.0.8748-alpha, and still persist after updated to latest version 2.5.0.8783 alpha

I am attaching the backtrace log
log-śr. lut 8 19-35-27 2023.txt

Version

2.5.0.8783 alpha

OS

Windows 10 Pro 21H2

[ronso0]

I can not confirm with 2.4-alpha-1419

Does it matter which track you load on deck2? Hotcues, no hotcues, cue loops, anything?

[RadioDM]

I thought the backtrace procedure would say it all.
Tldr: You might just skip to below the ####

So it doesn't matter what track I load on any deck. And after checking I agree it is not as simple as "turn cueloop on deck1 and load to deck2". The problem occur with some combination of these steps: on Deck1 put some hotcues, put cueloop and leave it active; on Deck2 turn On the Key Lock, put some hotcues, put cueloop, play, sync, eject and load the ejected track again.

The crash still occur if out of these steps above I do not use cueloop. So cueloop not a cause. But it possible will never happen if I dont turn Key Lock on.
. ####
This combination ALWAYS trigger crash: load deck, play, turn Key Lock on, stop, eject, load again.
Any track, hotcues not matter, cueloop not matter.

I attach my settings, and its Deere skin.

[RadioDM]

New Backtrace for the updates above
log-pt. lut 10 00-13-38 2023.txt

[daschuer]

DebugString: "Critical error detected c0000374"

EXCEPTION_BREAKPOINT

mixxx.WLabel::setText+6D mixxx.WTrackProperty::updateLabel+90
mixxx.WTrackProperty::slotTrackLoaded+14D

This crashing backtrace looks unsuspicious.
I am afraid it is something bad like a dangling pointer corrupting other memory.

Such issues are hard to fix remotely. So we need your help.

Is the Mixxxx 2.3.3 affected as well?
Maybe we can identify one of the developer builds that has introduced the issue.

[RadioDM]

So I had to uninstall Mixxx to install 2.3.3. And couldn't crash it with the same pattern.
So it is happening at least since 2.4.0.8748-alpha

[daschuer]

That's great.
Can you give the version shown in the about box? It looks like we have a bug in the version number that is shown in the *.exe preferences.

[RadioDM]

You are right. Luckily I have found the installer of this version in the bin. So it is:
Mixxx 2.4.0-alpha-pre
Git version: 2.4-alpha-1377-g86a280b5e0 (main)
Date: Monday, 26 December 2022 20:59:00
Platrofm: Windows x86_64

Do you want me to go through versions on this page to find a suspect one? http://downloads.mixxx.org/snapshots/2.4/
*Edit. Or not from link above as there are only latter versions. But maybe here? http://downloads.mixxx.org/snapshots/main/

[daschuer]

Yes, there is a good chance you find the version we can blame.
I suggest to start with one in the middle and than the middle of the reaming builds and so on.

[RadioDM]

So the problem starts with the: 2.4-alpha-1350-gf96d16875e (main)
Every checked intermediate earlier releases are fine, with the last one ok being 1349. And latter releases are affected all the same way to the main problem.

I'm pasting below the settings related to Key pitch, as I have them

[RadioDM]

Some additional notes. It appears EJECT is also co-offender here.
I keep one deck with key lock off, and one lock on. When I do combination load-play-stop-eject-load on a deck with key lock OFF which stays off, it goes fine. It's ok even if I turn the lock on and back off during play. And apparently on the deck with lock ON the same combination of load-play-stop-eject-load will give a crash. And any combination on any deck, where instead of EJECTing track I just stop and load another one straight away - then it goes fine.

[daschuer]

Greate, this means we can blame this one:
f96d16875e
I will create a test build that reverts that.

[daschuer]

@RadioDM Please try out this build: https://github.com/daschuer/mixxx/actions/runs/4181327888
You'll find to the windows installer at the bottom of the page. You need to be logged in to GitHub.

[RadioDM]

I have tested the release above. No more crashes, no matter what I try to make it again. Everything else is working as it should, AFAIC. Seems like a good job.
I don't know your policies here, so I think I will leave the closing of topic and changing it's name up to You

[daschuer]

Thank you for testing.
Unfortunately we are not ready, because this PR reintroduce another crashing issue.
I will prepare another PR to dig down the root cause and finally fix both issues.

[daschuer]

@RadioDM please try this build: https://github.com/daschuer/mixxx/actions/runs/4197090113
It is half of f96d16875e
It this crashing or not?

[RadioDM]

So the given test build gives crash. Hopefully the other half is not :D
Also, while this is not big issue, but for installation of this release and one other in recent days, the installation ended with weird outcome where there was no mixxx.exe file so the program would never start. In both cases I had to use installer again and choose "Repair" option. Not major, and don't know how much it is related and to what

[ronso0]

@RadioDM Please file another issue for that and let us know which builds it occurs with (releases from the Download page, or just PRs build by CI). Thank you!

[daschuer]

@RadioDM Please checkout this build. I have not yet found something obvious, so we need to narrow don possible changes.
https://github.com/daschuer/mixxx/suites/11209375200/artifacts/573412659

[RadioDM]

@RadioDM Please checkout this build. I have not yet found something obvious, so we need to narrow don possible changes. https://github.com/daschuer/mixxx/suites/11209375200/artifacts/573412659

Couldn't reproduce bug on this one.

[daschuer]

And this? https://github.com/daschuer/mixxx/suites/11219267741/artifacts/574162328
Hopefully the final one to find out the failing commit.

[RadioDM]

Couldn't crash this one too

[daschuer]

I was finally able to reproduce and hopefully fix this issue.
Since some of my builds are not crashing I am not 100 % sure it is fixed, but the change in #11334 is reasonable in any case.

[daschuer]

@RadioDM You will find a build for testing at the bottom of this page once the workflow has been finished: https://github.com/mixxxdj/mixxx/actions/runs/4344515264
Please Test.

[RadioDM]

@RadioDM You will find a build for testing at the bottom of this page once the workflow has been finished: https://github.com/mixxxdj/mixxx/actions/runs/4344515264 Please Test.

So, there is no that crash we were hunting, but this build gives another glitch meaning that (under conditions explained below) waveform overviews are now not loaded.

After a track was already once loaded onto deck during this Mixxx run, anytime I want to load that track again on any (empty!) deck, the waveform overview will not load (with intro, hotcues points visible properly). This will happen always for any track that was previously loaded during this run (no matter if was analysed before or not), but will NOT happen if I load previously played track on the NOT empty deck (I think the same conditions applied for crash/no-crash). Empty waveform on image:

Only once instead of empty waveform I had glitched waveform / wrong scaled. The wrong waveform would look the same every time I load it on empty deck, but only for this run of Mixxx. Image (top = glitch, bottom = normal):

This are my waveform settings, for sake of reproducing or anything :)

[daschuer]

Thank you for confirming that the crasher is fixed. I can confirm the issue with the waveform overview and it should be fixed with:
#11333
I will prepare another testing build for that.

[daschuer]

It will appear here as usual: https://github.com/mixxxdj/mixxx/actions/runs/4351344393

[RadioDM]

Yes, with this one there is no crash and no glitch

[daschuer]

Juchhu! Thank you for the good cooperation and your patience with this hard to crack nut.

[RadioDM]

@daschuer I still experience the glitch with wrong scaled waveform images. When it happens I must load the track again so the waveform display fine (never got a missing waveform glitch tho). Was it somehow fixed later? I am still on the latest version that has been mentioned here, and on mixx.org download page the alpha seems to be lower number (1425) that the one I got (1435)

[daschuer]

The casher fix has been merge to https://downloads.mixxx.org/snapshots/2.4/mixxx-2.4-alpha-1437-g96c5b4987e-win64.msi

The waveform glitch is fixed in mixxx-2.3.4-9-geeae59a9f9.msi
Merged to https://downloads.mixxx.org/snapshots/2.4/mixxx-2.4-alpha-1467-g425ad1e47a-win64.msi

We have not yet a 2.5 alpha with the fix. I have just merged it and will appear here: https://github.com/mixxxdj/mixxx/actions/runs/4633381583 once the build is finished.

[RadioDM]

Thank you for detailed response. So 2.4-alpha-1467 is the one I want. I just was confused as the mixxx.org website had the alpha version prior to mine. I probably again forgot the latest alpha 2.4 on the mixx.org is not the truly latest.
I will need more or less stable version for a time being so will stick to 1467, but I will come another time to give 2.5 a try.
Thanks again