crash loading tracks with GLSL waveforms on macOS with nVidia GeForce GT 750M

[Benis]

The only common trigger for this that I'm sure of is that it happens when I load a track into a deck. I can't find anything else consistent about what triggers this or doesn't.

The text 'Analyzing...' appears in the waveform overview, the position marker appears, and then the entire GUI excluding the cursor hangs, though that eventually stops responding too. The waveform overview never appears. Any track that was playing before the freeze will continue for a minute or two before I'm kicked out to the login screen.

Sometimes after about a minute, some of the info from the track that was ejected from the deck will reappear (such as elapsed time), but the GUI never recovers properly and eventually I'm back at the login screen.

I've tried numerous builds and releases and have reproduced the issue on all of them.

I'm on a MacBook Pro (Retina, 15-inch, Mid 2014)
macOS 10.13.6
2.8 GHz Intel Core i7 processor
Integrated GPU: Intel Iris Pro 1536 MB
Discrete GPU: NVIDIA GeForce GT 750M

This only appears to happen when using the discrete GPU, with waveforms set to RGB (GLSL). If I use a utility to force use of the Intel integrated graphics I have yet to see the crash occur.

Mixxx log file attached. Please let me know if I've missed anything or you need further information.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Mixxx is able to hang the OS? That sounds very strange!

The attached log file does not indicate that any files have been loaded before Mixxx has been shut down. Did you attach the correct log file?

Please try to reproduce the failure and and if possible attach the output of a backtrace:
https://www.mixxx.org/wiki/doku.php/creating_backtraces

[Benis (beenisss)]

I've attached the log file again following the latest crash, hopefully more revealing this time. Unfortunately I can't run a backtrace because it hangs my entire system and I can't get access to any other apps etc.

Is there a way to completely and thoroughly nuke Mixxx and all its settings and start over?

[Sean M. Pappalardo (pegasus-renegadetech)]

This type of problem can usually be traced back to a failing hard drive (where the OS is blocking waiting on the drive to read a bad sector.) Can you start up in Recovery mode and use Disk Doctor to check the drive for errors?

To answer your question, you can delete the .mixxx directory from your home directory to erase all Mixxx settings.

[Benis (beenisss)]

The Fiplab app you mean? I don't currently have it, will look into it if I get a chance. It seems a bit odd that something so specific would be caused by an SSD fault though.

[Sean M. Pappalardo (pegasus-renegadetech)]

Sure, but it also seems odd that a user-land application could cause the OS itself to hang. :) Unless there's a kernel bug in the version of the OS you have (are you on the latest?) that the Qt framework Mixxx uses is doing just the wrong thing to trigger. While it may not be the HD specifically, this type of thing is usually a hardware or driver problem. (Spinning HDs just tend to be the first hardware components to fail.)

[Sean M. Pappalardo (pegasus-renegadetech)]

Oh, that reminds me, in case it's a video driver problem, try changing the waveform rendering option in Mixxx's preferences to Software (or None) before you try to load a track and see if that helps.

[jus (jus)]

Can not confirm this crash with latest 2.1.0-beta1 (build 2.1 r6484) on macOS 10.13.2.
Tested with a Macbook way older than yours.

Can you give some more informations
* Where did you download from, or did you compile the app by yourself?
* Have you any kind of hardware attached ( midi controller, external soundcard,...)
* Is this with any skin ( Mixxx > Preferences > Interface > Skin)
* Do you have any kind of interface scaling active, default is 100% ( Mixxx > Preferences > Interface > Retina Scaling)
* Are only specific file type affected? Please test with loading different files ( e.g. m4a, mp3 etc).

Start Mixxx from the Terminal.app with the following command ( without quotes):
``/Applications/Mixxx.app/Contents/MacOS/Mixxx --developer``

This prints additional debug/developer messages to the terminal. Please post the output if the next crash occur. Or even better, additionally the output of the Apple crash reporter.

<quote>
Is there a way to completely and thoroughly nuke Mixxx and all its settings and start over?
</quote>
All settings and analysis files are in (without quotes)
``Library/Application Support/Mixxx``

Warning: Delete this folder - and be prepared to loose all saved data and custom settings (waveforms, replaygain/bpm/cover data, custom midi & keyboard settings etc.)

[Benis (beenisss)]

Hi everybody, thanks for all the tips etc. Managed to narrow this down some more, appears to be related to two things: a video/graphics issue of some kind, and files that *aren't* being loaded for the first time.

The common factor in all the crashes I've produced is having the waveform type set to RGB (GLSL). With that in mind, some steps that have consistently reproduced the issue for me:
Load a file that's never been used before into a deck
Load another file that's never been used before into the same deck
Reload the first file into that deck

When I have the waveform type set to RGB (GLSL), a file I've never used in Mixxx before will load fine, but anything else will hang. Once a file has been loaded for the first time, it will then hang the system if you re-load it after loading something else in its place (assuming that that something else doesn't hang the system first.)

If you start with the waveform type set to another option, load some new files and then switch to RGB (GLSL) again, it seems happy re-loading files you've just loaded for the first time, but if you pick something you already loaded in a previous session, that kills it.

If you load a never-before-used track, eject it then load it again, it doesn't have a problem with this.

I've tried using Clear > All to wipe the waveform, beatgrid and other info, but this doesn't help and these files will still hang the system.

To answer jus's questions, if the info is still useful:
* Downloaded this from http://downloads.mixxx.org/builds/2.1/release/mixxx-2.1.0-beta1-2.1-release-macintel64-latest.dmg
* No hardware attached
* Tried several skins, made no difference
* Interface scaling is set to default
* Not affected by file type as far as I can tell

Happy to do some more testing later and run some debugging stuff if it's still useful, but deliberately crashing my laptop over and over is starting to get old, and I'm running out of files that I've never loaded into Mixxx before. For now I'm just going to avoid using any GLSL waveform types.

[jus (jus)]

Thanks for the detailed report.
Still can not reproduce the crash with having RGB (GLSL) selected on my old machine with Intel HD Graphics 3000:

* Load never before played Track A to Deck 1 (do not play)
* Load never before played Track B to Deck 1, replacing Track A (do not play)
* Load Track A again in Deck 1, replacing Track B

Bug might be specific to some graphic cards. Since RGB (GLSL) is the default, we better get to the root of it.

If you open the ``Console.app`` under the *System Reports* tree, is there any recent file similar to `Mixxx_2018-01-***_username.crash``?
Right-click to locate the file in the finder ( /Library/Logs/DiagnosticReports )

[Benis (beenisss)]

Crash file attached.

[Benis (beenisss)]

Ugh the more I try to reproduce this the weirder and less consistent it seems to get.

On the plus side, I've found that sometimes with shorter files the system eventually recovers rather than permanently hanging. If I set up a bunch of extra short audio files, would any of the debugging routines above then be worth trying again?

[Launchpad Janitor (janitor)]

[Expired for Mixxx because there has been no activity for 60 days.]

[Benis (beenisss)]

Having looked at a couple of similar bugs - https://bugs.launchpad.net/mixxx/+bug/1789059 and https://bugs.launchpad.net/mixxx/+bug/1791510 - it's occurred to me I wasn't that descriptive when I said this hangs my entire system. It freezes the GUI (with the exception of the mouse cursor, though eventually that succumbs too), but if a track is playing the audio will continue for maybe a minute before the system quits and takes me to (for some reason) the login screen...

[Be (be.ing)]

I am doubtful this is the same as either of those bugs. In neither of those bugs does the cursor freeze or the system restarts. However, it is plausible that all these bugs have related causes.

[Be (be.ing)]

Also, neither of those other bugs seem to be related to loading tracks.

[Be (be.ing)]

I finally got backtraces for Bug #1789059 and those were related to loading tracks. However, the deadlocks were in /usr/lib64/libX11.so.6 not Qt or Mixxx, whereas the backtrace in comment #11 here indicates the crash is related to OpenGL, so these do seem to be separate bugs. I am a bit confused by the backtrace mentioning com.apple.GeForceGLDriver considering the machine does not have an nVidia GeForce GPU.

Ben, have you been able to reproduce this bug with 2.2 or master using Qt5?

[Benis (beenisss)]

This is the 'About this Mac' dialog.

[Benis (beenisss)]

This, on the other hand, is the System Report, which suggests I do in fact have a GeForce graphics card. Slightly misleading..

[Benis (beenisss)]

Be, in answer to your question, yes. I haven't yet found a build or release where this doesn't come up.

[Benis (beenisss)]

Well this is interesting, I've used gfxCardStatus to force either integrated (ie Intel) or discrete (ie NVIDIA) graphics before I launch Mixxx. I can't get it to crash while it's forced to use the integrated GPU, however I tried to load one track with the discrete GPU forced and it promptly crashed.

By default Mixxx uses the discrete GPU. I've mentioned in a couple of places including the original post that I'm using Intel Graphics and it turns out that isn't the case, which isn't ideal.

[Be (be.ing)]

Thanks for testing this further. It's not clear to me whether the bug is in Mixxx's OpenGL code or the nVidia driver. If the problem is in the driver, we still might be able to work around it in Mixxx.

Considering this bug is not new in 2.2, can be worked around, and only affects a specific combination of OS and GPU, I don't think this should be a release blocker for 2.2.0.

[Be (be.ing)]

Bumping the milestone back to 2.3.0 unless someone steps up to fix this now.

[Benis (beenisss)]

For whatever reason, I can't reproduce this any more. Not really sure what combination of things accounts for that but I am more than happy to see the back of it.

[Benis (beenisss)]

There isn't a 'Can't reproduce' or 'Fixed itself' status, but if somebody wants to close this, feel free.

[Daniel Schürmann (daschuer)]

OK I have set it to "Invalid" for now. Feel free to reopen it if the issue is back.

[Fabio Gi (oakwoodtheman)]

I have the exact same problem!

I run macOS High Sierra 10.13.4 (17E199) and Mixxx 2.2.0 (build 2.2 r6659).

I have the exact same symptoms reported by Benis: load, system freeze, mouse pointer disappearing, music continuing for half a minute and stopping, logout of the user and login screen.

I have tried with an older version of Mixxx (2.1.5) with the same results!

The problem disappears choosing "Filtered - Software" waveform type in the preferences.

I put the status back to "Confirmed"

[Daniel Schürmann (daschuer)]

Please post the mixxx.log file from a crashing run. https://www.mixxx.org/wiki/doku.php/finding_the_mixxx.log_file

Are only GLSL waveforms effected or GL waveforms as well?

[Daniel Schürmann (daschuer)]

Debug [Main]:
GLWaveformRendererSignalShader::loadShaders Warning [Main]: QString::arg: Argument missing: "Q" , 0 Warning [Main]: QString::arg: Argument missing: "IN" , 0 Warning [Main]: QString::arg: Argument missing: "OUT" , 0 Warning [Main]: QString::arg: Argument missing: "C" , 0 Warning [Main]:

This is suspicious in the log posted by benis.

[Be (be.ing)]

Fabio, what GPU are you using?

[Benis (beenisss)]

For the record I haven't seen this issue since I last commented, and I've been using GLSL the whole time.

Perhaps more relevant, I forget when I upgraded to Mojave but I think it was in early December, and it may well have coincided with this issue going away.

[Foss-4 (foss-4)]

Since Benis can no longer reproduce, @fabio: are you still seeing this crash with macOS 10.13.6 and mixxx 2.2.1?

Should the problem persist, could you share, which GPU you are using?

[Daniel Schürmann (daschuer)]

I have set this to incomplete, because it was magically fixed.
If it occurs again, please reopen it and attach the recent mixxx.log.

[Launchpad Janitor (janitor)]

[Expired for Mixxx because there has been no activity for 60 days.]

[Swiftb0y (swiftb0y)]

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