SIGSEGV on controller thread when enabling a MIDI controller on Mixxx 2.4 #12001
Labels
Milestone
Comments
|
Thats very strange. Are you able to compile from source? If so can you try the newest commit on the |
|
@Swiftb0y I just tried and, strangely enough, with the sanitizers enabled the crash doesn't happen anymore and my controller works fine. I don't see any message on the logs either. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
The crash is miles away from our code. I fear this is some race condition that corrupts the stack somewhere else. Instead of |
|
@Swiftb0y ok, I'll try to continue debugging locally, and if you need more details on my setup to try to reproduce the issue, let me know. |
|
It probably depends on circumstances I can't reproduce (processor speed, system usage, etc). But thank you for looking into it. Please share your findings and I'll try to help you as much as I can. |
|
@Swiftb0y after further testing it seems the bug occurs when I enable any MIDI controller. The HID ones do not trigger the crash. Can you try enabling a MIDI device with and let me know if you can reproduce it? It doesn't matter which device or what mapping you assign to it, as long as it's a MIDI device. |
napaalm
changed the title
|
I can't reproduce it on my end unfortunately. Not in a debug build at least. Currently waiting for the release build to finish compiling. |
|
Same for the release build... |
|
The last call under our control is here: This seems a pretty independent call form our code. This is pointer in this makes the object owned by the QObject tree. The double ownership is suspicious. But that does not explain the crash .. :-/ |
This comment was marked as resolved.
This comment was marked as resolved.
|
@daschuer @Swiftb0y I just finished bisecting, and here are my results.
I find very amusing the fact that I get the same exact crash on every single build of mixxx from branch 2.4 since 2020, while on mixxx 2.3 it just works. |
|
Thank you for going through the tedious bisecting work. So in 2.3 we changed from the then outdated and now removed QScriptEngine to QJSEngine. The commits you're referencing are the exact commits that committed the switch, so in short QJSEngine never worked on your system at all for some reason. So I'm pretty sure the issue is not related to Mixxx itself but rather QJSEngine in general. Can you try to build some minimal QJSEngine example and see whether that also crashes on your system? You can build one yourself or just use some random public code like https://github.com/tarcisiofischer/QJSEngine-playground |
@Swiftb0y does the 2.3 branch use it too? Because I get this crash only on branch 2.4. Release 2.3.6, for example, works perfectly for me. |
I just ran that simple test and it doesn't crash. I think there's something more subtle going on here. |
It doesn't, 2.4 is the first release with QJSEngine.
Probably yeah, I forgot we already established that it doesn't crash under ASAN. I have no idea how to debug this further. Have you tried running mixxx on a different system? I'm afraid I don't have any better idea on how to work around the issue. I don't even know how to properly diagnose it. I guess you could try adding some arbitrary sleep calls during initialization. I'm guessing the problem is some data race causing memory corruption, and the slower execution during ASAN causes it to not occur. Maybe |
|
@Swiftb0y with This data race seems to be triggered at the exact point where normally it crashes. Maybe we have found it! |
|
@daschuer @Swiftb0y by using valgrind I got some more info on the crash. |
|
And here's the output from helgrind: helgrind.log |
|
We have a write to the same memory here: |
@daschuer TSAN changes the software behavior like ASAN did (in fact mixxx doesn't crash with it enabled), so this data race might not be the exact cause of the sigsegv. By using helgrind instead I still get the correct crash, so maybe you can find more pertinent information there. I'm attaching again the full TSAN and helgrind logs for your convenience. |
|
@daschuer @Swiftb0y I have one more piece of information: while running Mixxx with Does this have anything to do with my crash? As always, here's the full log: valgrind.log |
|
It looks like the conditional jump happens in a library without debug information for 0x1C22B301 and 0x1A62BBC7. You may add a breakpoint at these addressed to get an idea where the point is. The memory itself should be a short live time memory used in QTextStream: mixxx/src/skin/legacy/legacyskin.cpp Line 97 in c1665e5 I am afraid we cannot do much about it. |
|
For more context, I created a thread about this on Zulip back in July: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/QJSEngine.20segfaulting.20on.20initializing/near/375832083 I remember everything working fine with |
|
I'd also add that mixxx build optimizations don't affect this bug: I tried with |
|
As we've just discussed on Zulip, it turns out that the crash is caused by a failed while (madvise(result, bytes, MADV_DONTNEED)) {
if (errno != EAGAIN)
CRASH();
}The reason of the failure is that there's a previous call to The reason of the @Swiftb0y then wrote a minimal example that I will now report to the Qt bug tracker #include <sys/mman.h>
#include <QCoreApplication>
#include <QDebug>
#include <QJSEngine>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
qDebug() << QT_VERSION_MAJOR << QT_VERSION_MINOR << QT_VERSION_PATCH;
// lock memory (as done by for example Pipewire with a Pro-Audio config).
mlockall(MCL_CURRENT|MCL_FUTURE);
QJSEngine engine;
// no need to do anything else, we've crashed by now.
return a.exec();
} |
|
I just opened QTBUG-120450. |
|
IIUC this is not a Mixxx issue (and we can't do much except wait for it being fixed upstream) so we can remove it from the 2.4 milestone, right? |
|
We should probably document the workaround somewhere (set Do we have a "known issues" document or section in the documentation? |
None that I'm aware of unfortunately. |
Well, one's custom config file might be somewhere else or have a different name, and also by default it's |
|
+1 removing this issue from the milestone / closing it as Not Our Bug |
|
(and adding something to our Known Issues / Release Notes) |
|
Alright, I'll close it, leave it in 2.4 and add |
|
The issue has been solved upstream for all currently maintained versions of Qt (5.15 included): https://bugreports.qt.io/browse/QTBUG-120450 |
|
Perfect Thank you for taking care. I will update the Changelog accordingly. |
|
For my understanding it is a Linux regression introduced in |
|
@daschuer yes, exactly |
|
@daschuer the fix has been merged in the KDE repo for Qt 5.15. https://invent.kde.org/qt/qt/qtdeclarative/-/merge_requests/56 So, at least on Arch, it's fixed in qt5-declarative version 5.15.12+kde+r32-1 onwards. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Description
A build of Mixxx from the 2.4 branch (at c104752) crashes during startup if my controller (an Hercules DJControl Starlight) is enabled. The same crash happens if the controller is disabled and then I enable it in the preferences menu.
The following is a backtrace from a debug build. Unfortunately the full backtrace exceeds the 65535 character limit, so I tried to omit the irrelevant parts. Let me know if you need something else.
Version
2.4
OS
Arch Linux with Pipewire and Sway (Wayland)
The text was updated successfully, but these errors were encountered: