Ubuntu
mixxx package

SIGILL on i386

Bug #1793202 reported by errors.ubuntu.com bug bridge
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Won't Fix
Undecided
Unassigned
mixxx (Ubuntu)
New
Undecided
Unassigned

Bug Description

The Ubuntu Error Tracker has been receiving reports about a problem regarding mixxx. This problem was most recently seen with package version 2.0.0~dfsg-7.1, the problem page at https://errors.ubuntu.com/problem/93e4b76250e8d6118161e71aedb269dc95ef67e4 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.

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

This has been reported 75 times in the last year according to errors.ubuntu.com.

Notably, almost all the CPUs do not have SSE2, and we build with SSE2. So that's (SSE2 instructions) probably where the SIGILL is coming from. The stack trace is in the static initialization phase right when mixxx starts up.

I don't know if we care, but it's worth noting that happens.

summary: - /usr/bin/mixxx:4:mixxx::track::io::Bpm::SharedCtor:mixxx::track::io::protobuf_AddDesc_proto_2fbeats_2eproto:__libc_csu_init:__libc_start_main:_start
+ SIGILL on i386
Changed in mixxx:
status: New → Confirmed
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Instead of crashing, we can warn the user and suggest to build Mixxx build on their own.

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

What would be the best way to do that? Since this crash is in static initialization, we don't have the chance to add a check in main(). If we had a wrapper script that runs mixxx we could do it there, but I'm not sure that's the best way?

It looks like since Artful, there is an i386 universe package called "sse2-support"
https://packages.ubuntu.com/bionic/sse2-support
that prevents installation if the user's CPU doesn't have SSE2. That seems like a good solution?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Sounds like a good solution.
How does this work on none x86 architectures?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

The same issue may effect our other 32 bit targets. Do we reach main() with sse2 enabled and msvc?

Is there a way to not use sse2 during the initialisation before main? This would allow us to check for sse2 at runtime without any pain.

Or we may just ignore this issue and wait until all non sse2 CPUs have died. ...

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

If we enforce SSE2 in our own init code, people without SSE2 couldn't build Mixxx without hacking it. So I second having our Ubuntu package depend on the sse2-support package. Or if there are many non-SSE2 users, should we be building our x86 package without it?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

With sse2 support I am able to use Mixxx on my old Netbook. If we remove it, we have a regression for these devices in favour of older devices which may not be usable anyway.

If we decide to add SEE enforcement code into Mixxx, it will be conditional for sse2 builds.
So there is no hacking required to build non sse2 version. We have already the optimize=native flag, which should do the trick for all targets.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Won't fix because almost all Devices have sse2 now.

tags: removed: artful yakkety zesty
Changed in mixxx:
status: Confirmed → Won't Fix
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9441

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.