Mixxx crashes on first time jog wheel touch + movement after fresh start of macOS

[Max Beiersdorfer]

I get sporadic segmentation fault crashes during normal playback of one deck at my gigs. The second deck has a loaded but stopped track in it.
The crash can happen after 1 hour of playing or after 4 hours. I could't figure out any special step to reproduce the crash yet and normally it happens only after a long time of playing. That's why I don't have any backtrace data yet. The last time the crash happened, it happened twice within a short time period as the Auto-DJ was active.

Mixxx: 2.1.0-beta1 (build 2.1 r6501)
OS: Apple macOS High Sierra 10.13.3 (17D47)
CPU: 1,6 GHz Intel Core i5
Video: Intel HD Graphics 6000 1536 MB
Sound: Apple Core driver -> Pioneer DDJ-SX

Another problem I have (and I don't know if it's the origin) is that such segmentation fault crashes also occur after a fresh start of macOS and a fresh start of Mixxx during the first touch and movement of a deck's jog wheel (scratch). I'm using the Pioneer DDJ-SX, the Hercules DJ Console RMX4 or the Hercules DJ Console 4-MX. But this occurs only on this macOS. I have an older MacBook with macOS 10.12 (I think) where the first touch doesn't allow any scratching. It only holds the track. On the second touch I can scratch.

I attached the macOS error report after crashing as the Auto-DJ was active.

[Uwe Klotz (uklotzde-deactivatedaccount)]

The crash is most likely caused by a known bug in the 2.1 beta release. Sorry for that, the fix is still pending to be merged:
https://bugs.launchpad.net/mixxx/+bug/1749800

[jus (jus)]

Now that the fix for lp:1744550 is merged, please test the current version again.

[Uwe Klotz (uklotzde-deactivatedaccount)]

The second issue seems to be unrelated to the fix, but the crashes during regular usage should be fixed. I just noticed that I pasted the wrong URL and referenced this same bug report ;)

We should change the title to match the second issue and keep this bug report open until the remaining issues are fixed.

[Max Beiersdorfer (max-beiersdorfer)]

Thank you for the information! I renamed the title according the second issue. I hope I can find time on the weekend to focus on that issue and get some backtrace data.

[Max Beiersdorfer (max-beiersdorfer)]

I was able to reproduce the crash!

Conditions:
- Fresh macOS start
- Connected midi controller
- Mixxx is started with internal sound card configured as sound output in the settings

Actions after starting Mixxx:
- Before doing anything else, I change the sound output in the settings to my external controller sound card
- Apply the changes and close the settings window
- Load a song to Deck 1
- Start playback of Deck 1 (by pressing play on the skin or on my controller)
- During playback I touch/press the jog wheel on my controller for the first time and try to move it.

Results (2 behaviors):
1. Playback is stopped as long as I touch the jog wheel but as I move the jog wheel nothing will happen (expected behavior is scratching). On releasing and touching the jog wheel again I am able to scratch.
2. Playback is stopped and Mixxx crashes!

I was able to create back-traces for the crash:

Last login: Sun Mar 11 13:11:01 on console
Maximilians-Air:~ DJMaxergy$ lldb /Applications/Mixxx.app/Contents/MacOS/mixxx
(lldb) target create "/Applications/Mixxx.app/Contents/MacOS/mixxx"
Current executable set to '/Applications/Mixxx.app/Contents/MacOS/mixxx' (x86_64).
(lldb) run
Process 558 launched: '/Applications/Mixxx.app/Contents/MacOS/mixxx' (x86_64)
2018-03-11 13:14:16.718283+0100 mixxx[558:7152] WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.3 instead of 10.13.3. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
Call location:
2018-03-11 13:14:16.719491+0100 mixxx[558:7152] 0 CarbonCore 0x00007fff532e73d8 ___Gestalt_SystemVersion_block_invoke + 112
2018-03-11 13:14:16.719520+0100 mixxx[558:7152] 1 libdispatch.dylib 0x00007fff799fcd50 _dispatch_client_callout + 8
2018-03-11 13:14:16.719539+0100 mixxx[558:7152] 2 libdispatch.dylib 0x00007fff799fcd03 dispatch_once_f + 41
2018-03-11 13:14:16.719556+0100 mixxx[558:7152] 3 CarbonCore 0x00007fff53277da0 _Gestalt_SystemVersion + 948
2018-03-11 13:14:16.719572+0100 mixxx[558:7152] 4 CarbonCore 0x00007fff532775e6 Gestalt + 139
2018-03-11 13:14:16.719589+0100 mixxx[558:7152] 5 QtCore 0x0000000100e5d6cc _ZN16QSettingsPrivate6createEN9QSettings6FormatENS0_5ScopeERK7QStringS5_ + 76
2018-03-11 13:14:16.719606+0100 mixxx[558:7152] 6 QtCore 0x0000000100e3f042 _ZN9QSettingsC1ERK7QStringS2_P7QObject + 34
Warning [Main]: Configuration file is at version "2.1.0-alpha-pre" instead of the current 2.1.0-beta1
Warning [Main]: QFileInfo::absolutePath: Constructed with empty filename
Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[Microphone]" , "show_microphone" )
Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[VinylControl]" , "show_vinylcontrol" )
Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[PreviewDeck]" , "show_previewdeck" )
Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[Library]" , "show_coverart" )
Warning [Main]...

[Max Beiersdorfer (max-beiersdorfer)]

Add: In this case I used the following midi controller: Hercules DJ Console RMX 2.
But the crash occurs with my Pioneer DDJ SX and my Hercules DJ Console 4 MX, too.

For easier analysis I attached the back-trace as rtf file.

[Max Beiersdorfer (max-beiersdorfer)]

I also attach the Apple crash report which is being generated after the crash.

[Max Beiersdorfer (max-beiersdorfer)]

I used the latest beta build: 2.1.0-beta1 (build 2.1-r6518) for reproducing the crash.

[Be (be.ing)]

Can anyone else reproduce this? I have no controllers with jog wheels to test with.

[Be (be.ing)]

> Results (2 behaviors):
1. Playback is stopped as long as I touch the jog wheel but as I move the jog wheel nothing will happen (expected behavior is scratching). On releasing and touching the jog wheel again I am able to scratch.
2. Playback is stopped and Mixxx crashes!

I am a bit confused by this description. When exactly does it crash? Does it only crash when touching the jog wheel for the first time on some occasions or every time?

In the future, please attach logs and backtraces as plain text files rather than RTF.

[Max Beiersdorfer (max-beiersdorfer)]

Ok, a more detailed description:

Crashing case:

Conditions:
- Fresh macOS start
- Connected midi controller
- Mixxx is started with internal sound card configured as sound output in the settings

Actions after starting Mixxx:
- Before doing anything else, I change the sound output in the settings to my external controller sound card
- Apply the changes and close the settings window
- Load a song to Deck 1
- Start playback of Deck 1 (by pressing play on the skin or on my controller)
- During playback I touch/press the jog wheel on my controller for the first time and try to move it.

Result:
Mixxx crashes as soon as I try to move the jog wheel (jog wheel is still pressed to use the scratch function).

If Mixxx has crashed and I restart Mixxx without restarting my MacBook, the result during the first jog wheel touch including movement can be another crash or the playback just stops during jog wheel movement. As soon as I release the jog wheel and press and move it again...the scratch function works as expected.
I could reproduce this behavior on two different MacBooks and three different midi controllers.
I just could figure out any structure of what happens after the first crash and restart of Mixxx (crashing or just stopping playback during first scratch).

[Daniel Schürmann (daschuer)]

Does it also happy if you try to scratch waveforms by mouse?

Can you watch the memory that is consumed by Mixxx?

Does anyone know why we have no debug symbols included in the Mac version?

[jus (jus)]

I could not reproduce the crash using 2.1.0-beta1 (build 2.1 r6543), macOS 10.13.3 , Vestax VCI-300

CoreAudio 44100Hz @11.6ms
Output= VCI 300
Input=None

Followed step by step as outlined in #12.

@max
* Have you any other inputs/outputs active in Preferences > Sound hardware ?
* Have you multiple controllers connected, and active within Mixxx ?
* Have you customized your controller scripts, or loaded the stock scripts from Preferences > Controllers?

If you launch Mixxx from the terminal
``
/Applications/Mixxx.app/Contents/MacOS/Mixxx --developer --controllerDebug
``
and make it crash again, can you post the output from the terminal...

[Max Beiersdorfer (max-beiersdorfer)]

@Daniel:
By trying to scratch waveforms by mouse it doesn't crash. Just the expected behavior.
The memory consumed by Mixxx is about 630 MB to 750 MB just before the crash.

@jus:
My sound configuration at Mixxx startup is:
CoreAudio 44100Hz @9.00227ms (Audio buffer setting 2.9ms)
Only Master = Build-In output Channel 1-2

Then before playing any song, I go to the settings after Mixxx startup and change the sound configuration to:
CoreAudio 44100Hz @4.96559ms (Audio buffer setting 2.9ms)
Master = DJConsole Rmx2 Channel 1-2
Headphones = DJConsole Rmx2 Channel 3-4

This configuration is equal to my other DJ/Midi Controllers (Hercules DJ Console 4-MX, Pioneer DDJ-SX).

Then I load a song to Deck 1, press play and try to touch and move the jog wheel. As soon as I move the jog wheel Mixxx crashes.

I have just one controller connected at a time.
The crash happens with the stock controller scripts and my customized scripts.

If I launch Mixxx from the terminal using "/Applications/Mixxx.app/Contents/MacOS/Mixxx --developer --controllerDebug" I was not able to reproduce the crash anymore. In this case the scratching works at the first time touching and moving the jog wheel (as expected). In the past I had the crash using the terminal, too.

[Max Beiersdorfer (max-beiersdorfer)]

This is my sound config file just before the crash

[Be (be.ing)]

Are you able to compile Mixxx yourself using the optimize=off option with scons to get a backtrace with debugging symbols?
https://mixxx.org/wiki/doku.php/compiling_on_os_x

[Daniel Schürmann (daschuer)]

Don't use optimize=off Mixx will be unusable slow. The optimize flag does not set or remove the debug symbols.
It could be the debug flag. But I can remember that we have decided to always pack the symbols with Mixxx. Isn't this the case fro Mac?

[Max Beiersdorfer (max-beiersdorfer)]

I'm sorry @Be but I am still not able to compile Mixxx myself as described here: https://www.mixxx.org/forums/viewtopic.php?f=3&t=9348

It would be great if I could get the compile process running at some point. Under Fedora it's working as described.

[Be (be.ing)]

Using optimize=native removes the debugging symbols for me with GCC on GNU/Linux. I have to use optimize=off for backtraces to be helpful. I do not notice any appreciable difference in speed between optimize=off and optimize=native.

[jus (jus)]

@max

Reading the forum thread #19, i understand that you try to compile by using QT5, and it failed.

The following steps should allow you to compile the mixx source with qt4. This works for me since ages, currently with macOS 10.13.3. Qt4 is the mixxx default, qt5 support still experimental.

* Install qt4
  -----------
  brew tap cartr/qt4
  brew tap-pin cartr/qt4
  brew install qt@4

* Delete scons cache (from mixxx build dir root)
  ----------------------------------------------
  scons --clean

  manually remove the following files

  .sconsign.dblite
  .sconsign.tmp
  .sconf_temp
  config.log

* build (from the mixx build dir root)
  ------------------------------------
  scons stdlib=libc++

  This should invoke a build with the following flags:
  asan=0 battery=0 buildtime=1 bulk=0 color=0 coreaudio=1 faad=0 ffmpeg=0 hid=1
  hss1394=1 ipod=0 localecompare=0 macappstore=0 mad=0 mediafoundation=0 modplug=0
  opengles=0 optimize=portable opus=0 perftools=0 perftools_profiler=0 profiling=0
  qdebug=1 qt_sqlite_plugin=0 qtkeychain=0 shoutcast=1 test=False tsan=0 ubsan=0
  vamp=1 verbose=1 vinylcontrol=1 wv=0

* launch mixxx from build dir
  ---------------------------
  ./mixxx --controllerDebug --resourcePath res

  or

 ./mixxx --developer --controllerDebug --resourcePath res

  or just

  ./mixxx --resourcePath res

  There is no need to build a bundle (``scons bundle``) after building from source,
  when testing local.

Hopefully this will allow you to build from source, reproduce the bug, and provide another backtrace to pin this down.

[Daniel Schürmann (daschuer)]

The symbols are included with the -g compiler switch

with optimize=native I get

-c -pipe -Wall -Wextra -g -O3 -ffast-math -funroll-loops -fomit-frame-pointer -march=native -pthread -DT_LINUX

with optimize=off I get
-c -pipe -Wall -Wextra -g -pthread -Dx86_64 -DMIXXX_BUILD_DEBUG -D__LINUX__ -D__UNIX__

Both version have the -g

I have found stripcode for MacOs though which removed the debug info:
https://github.com/mixxxdj/mixxx/blob/d67bd7fe9913d046171944a12751f22754182a26/build/osx/OSConsX.py#L282

https://github.com/mixxxdj/mixxx/blob/d67bd7fe9913d046171944a12751f22754182a26/build/osx/OSConsX.py#L192

I do not know how it works.

[Daniel Schürmann (daschuer)]

Since we have no progress here, I move it from the 2.1 Milestone scheduled tomorrow.
A fix can go to a point release.

[Be (be.ing)]

Max, are you able to compile with Qt4 using jus' instructions above?

[Be (be.ing)]

This is a very serious bug. I am not comfortable releasing 2.1 until we at least get a good backtrace for this.

[Max Beiersdorfer (max-beiersdorfer)]

First of all: under Windows I could not reproduce the crash using the same midi controllers.

I tried to compile Mixxx with the instructions by jus...but failed again:

Maximilians-MacBook-Air:MacOS DJMaxergy$ brew tap cartr/qt4
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
amber libdill
arm-linux-gnueabihf-binutils libjwt
ask-cli libomp
auditbeat libsbol
augustus libserialport
autopep8 libtomcrypt
ballerina llvm@5
bamtools lm4tools
bareos-client lmod
bcal lzfse
bcftools mafft
bedops mariadb-connector-odbc
bioawk maxwell
blast mdcat
boost-python3 mill
bwa mint
caffe mmseqs2
calicoctl monero
chrome-export mpir
clblast neomutt
console_bridge nyx
container-diff ocrmypdf
coreos-ct octomap
cp2k odpi
darksky-weather opencascade
dartsim openimageio
dashing orocos-kdl
defaultbrowser parallelstl
diamond php-cs-fixer
docker-squash plank
draco posh
dynare primer3
elektra python@2
fastme qsoas
fcl qtkeychain
field3d restview
flintrock rtptools
fruit samtools
fselect scrcpy
futhark seqtk
ghc@8.2 shelltestrunner
git-sizer shogun
glances sickle
go-bindata siril
go-statik skaffold
go@1.9 skafos
gocryptfs spades
goto sratoolkit
gox srt
gpredict stellar-core
grv stress-ng
gtksourceview@4 telnetd
hlint terraforming
hmmer tj
howdoi tmux-xpanes
hss tnftp
icemon tnftpd
jdupes tomcat@8
jthread...

[Max Beiersdorfer (max-beiersdorfer)]

OK, I came a bit further, but still reached an error during build process:

[CXX] src/sources/soundsourceflac.cpp
[CXX] src/sources/soundsourceoggvorbis.cpp
[CXX] src/sources/soundsourceopus.cpp
In file included from src/sources/soundsourceopus.cpp:1:
In file included from src/sources/soundsourceopus.h:5:
/usr/local/include/opus/opusfile.h:110:11: error: 'opus_multistream.h' file not
      found with <angled> include; use "quotes" instead
# include <opus_multistream.h>
          ^~~~~~~~~~~~~~~~~~~~
          "opus_multistream.h"
1 error generated.
scons: *** [osx64_build/sources/soundsourceopus.o] Error 1
scons: building terminated because of errors.

[Daniel Schürmann (daschuer)]

That is what I have found on the web:
You can either edit the file as proposed or set the Xcode build setting "Always Search User Paths" to YES.

[Max Beiersdorfer (max-beiersdorfer)]

As far as I've seen this setting is only available inside a Xcode project file which I don't have (I think?). I didn't find this setting in the Xcode preferences itself.

[Be (be.ing)]

We have changed the build system to keep debugging symbols in the macOS builds. Max, can you try to reproduce this with the latest build from http://downloads.mixxx.org/builds/2.1/release/mixxx-2.1.0-rc1-2.1-release-macintel64-latest.dmg and attach a backtrace?

[Be (be.ing)]

Now that I have access to a Mac, I tried hacking the Xone K2 mapping to map one of the encoders like a jog wheel with engine.scratchEnable/scratchDisable/scratchTick and cannot reproduce this with 2.1 RC build 6652. This is on a Mid 2011 MacBook Air running macOS 10.13.1.

[RJ Skerry-Ryan (rryan)]

> # include <opus_multistream.h>
> ^~~~~~~~~~~~~~~~~~~~
> "opus_multistream.h"

@Max, that's an unfortunate, known bug in the Homebrew opus package. See the workaround in the Step 4 of the compilation instructions:
https://mixxx.org/wiki/doku.php/compiling_on_os_x#compile_and_install

Basically define:
export CFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus"
export CXXFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus"
before running scons.

[Max Beiersdorfer (max-beiersdorfer)]

Sorry for the late answer, I was on Easter holidays.

@RJ Ryan: I already considered the workaround after my last post here and got another error (last state before giving it up):

Maximilians-MacBook-Air:mixxx DJMaxergy$ HOMEBREW_PATH=/usr/local
Maximilians-MacBook-Air:mixxx DJMaxergy$ export CFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus -I/usr/local/include/opus -I/usr/local/opt/qt/include -I/usr/local/opt/openssl/include"
Maximilians-MacBook-Air:mixxx DJMaxergy$ export CXXFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus -I/usr/local/include/opus -I/usr/local/opt/qt/include -I/usr/local/opt/openssl/include"
Maximilians-MacBook-Air:mixxx DJMaxergy$ export LDFLAGS=-L$HOMEBREW_PATH/lib
Maximilians-MacBook-Air:mixxx DJMaxergy$ scons stdlib=libc++
scons: Reading SConscript files ...
INFO:root:Target Platform: osx
INFO:root:Target Machine: x86_64
INFO:root:Build: debug
INFO:root:Toolchain: gnu
INFO:root:Crosscompile: NO
INFO:root:Qt path: /usr/local/Cellar/qt@4/4.8.7_3
Automatically detecting Mac OS X SDK.
XCode developer directory:/Applications/Xcode.app/Contents/Developer
Found OS X SDK:macosx10.13
Automatically selected OS X SDK:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
Checking whether the C++ compiler works... (cached) yes
Configuring MixxxCore
Configuring SoundTouch
Configuring ReplayGain
Configuring Ebur128Mit
Checking for C library ebur128... (cached) no
Checking for C library libebur128... (cached) no
Checking for C header file sys/queue.h... (cached) yes
Configuring PortAudio
Checking for C library portaudio... (cached) yes
Configuring PortMIDI
Checking for C library porttime... (cached) no
Checking for C library libporttime... (cached) no
Checking for C header file porttime.h... (cached) yes
Checking for C library portmidi... (cached) yes
Checking for C header file portmidi.h... (cached) yes
Configuring Qt
Configuring TestHeaders
Configuring FidLib
Configuring SndFile
Checking for C library sndfile... (cached) yes
Checking whether SFC_SET_COMPRESSION_LEVEL is declared... (cached) yes
Configuring FLAC
Checking for C header file FLAC/stream_decoder.h... (cached) yes
Checking for C library libFLAC... (cached) yes
Configuring OggVorbis
Checking for C library libvorbisfile... (cached) yes
Checking for C library libvorbis... (cached) yes
Checking for C library libogg... (cached) yes
Checking for C library libvorbisenc... (cached) yes
Configuring OpenGL
Checking for C library GL... (cached) no
Checking for C library opengl32... (cached) no
Checking for C header file OpenGL/gl.h... (cached) yes
Checking for C library GLU... (cached) no
Checking for C library glu32... (cached) no
Checking for C header file OpenGL/glu.h... (cached) yes
Configuring TagLib
Checking for C library tag... (cached) yes
Configuring ProtoBuf
Checking for C library libprotobuf-lite... (cached) yes
Configuring Chromaprint
Checking for C library chromaprint... (cached) yes
Configuring RubberBand
Checking for C library rubberband... (cached) yes
Configuring SecurityFramework
Configuring CoreServices
Configuring IOKit
Configuring QtScriptByteArray
Configuring Reverb
Configuring FpClassify...

[Max Beiersdorfer (max-beiersdorfer)]

At the moment I'm only able to reproduce the crash using the latest build if I don't use backtracing.
Using backtracing I get the behavior that Mixxx doesn't do scratching while touching and moving the jog wheel for the first time (after starting Mixxx). This would also be the crash situation when I'm not using backtracing.
On touching and moving the jog wheel for the second time I get the expected behavior (scratching).

How else can I submit you the necessary information to see what's happening here?
What else can I do?

Again the actual procedure to generate the crash:
- Booting up MacOS
- Plugging in the MIDI controller
- Starting the terminal and enter "lldb /Applications/Mixxx.app/Contents/MacOS/mixxx"
- After that enter "run"
- Now in Mixxx go to the preferences and change the master sound output to the controller sound card channel 1-2 and headphones sound output to the controller sound card channel 3-4 (setting before is "Build-in sound".
- Apply the settings and close the preferences window.
- Load a track to Deck 1 and press play.
- Touch and move the jog wheel -> Track is just stopped/paused instead of scratching back and forth.
- Release jog wheel -> Track is playing again.
- Touch and move the jog wheel again -> Expected scratching is working.

[RJ Skerry-Ryan (rryan)]

Do you always install Qt via homebrew or have you ever installed it via
Qt's installer packages?

Can you share the contents of /usr/local/bin ?

FWIW, I don't install Homebrew to /usr/local, I install it to
$HOME/.homebrew.

On Mon, Apr 9, 2018 at 12:57 PM, Max Beiersdorfer <
<email address hidden>> wrote:

> Sorry for the late answer, I was on Easter holidays.
>
> @RJ Ryan: I already considered the workaround after my last post here
> and got another error (last state before giving it up):
>
> Maximilians-MacBook-Air:mixxx DJMaxergy$ HOMEBREW_PATH=/usr/local
> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
> CFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus
> -I/usr/local/include/opus -I/usr/local/opt/qt/include
> -I/usr/local/opt/openssl/include"
> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
> CXXFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus
> -I/usr/local/include/opus -I/usr/local/opt/qt/include
> -I/usr/local/opt/openssl/include"
> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
> LDFLAGS=-L$HOMEBREW_PATH/lib
> Maximilians-MacBook-Air:mixxx DJMaxergy$ scons stdlib=libc++
> scons: Reading SConscript files ...
> INFO:root:Target Platform: osx
> INFO:root:Target Machine: x86_64
> INFO:root:Build: debug
> INFO:root:Toolchain: gnu
> INFO:root:Crosscompile: NO
> INFO:root:Qt path: /usr/local/Cellar/qt@4/4.8.7_3
> Automatically detecting Mac OS X SDK.
> XCode developer directory:/Applications/Xcode.app/Contents/Developer
> Found OS X SDK:macosx10.13
> Automatically selected OS X SDK:/Applications/Xcode.app/Co
> ntents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
> Checking whether the C++ compiler works... (cached) yes
> Configuring MixxxCore
> Configuring SoundTouch
> Configuring ReplayGain
> Configuring Ebur128Mit
> Checking for C library ebur128... (cached) no
> Checking for C library libebur128... (cached) no
> Checking for C header file sys/queue.h... (cached) yes
> Configuring PortAudio
> Checking for C library portaudio... (cached) yes
> Configuring PortMIDI
> Checking for C library porttime... (cached) no
> Checking for C library libporttime... (cached) no
> Checking for C header file porttime.h... (cached) yes
> Checking for C library portmidi... (cached) yes
> Checking for C header file portmidi.h... (cached) yes
> Configuring Qt
> Configuring TestHeaders
> Configuring FidLib
> Configuring SndFile
> Checking for C library sndfile... (cached) yes
> Checking whether SFC_SET_COMPRESSION_LEVEL is declared... (cached) yes
> Configuring FLAC
> Checking for C header file FLAC/stream_decoder.h... (cached) yes
> Checking for C library libFLAC... (cached) yes
> Configuring OggVorbis
> Checking for C library libvorbisfile... (cached) yes
> Checking for C library libvorbis... (cached) yes
> Checking for C library libogg... (cached) yes
> Checking for C library libvorbisenc... (cached) yes
> Configuring OpenGL
> Checking for C library GL... (cached) no
> Checking for C library opengl32... (cached) no
> Checking for C header file OpenGL/gl.h... (cached) yes
> Checking for C library GLU... (cached) no
> Checking for C library glu32... (cached) no
> Checking for C header file OpenGL/glu.h....

[Max Beiersdorfer (max-beiersdorfer)]

Add: Procedure is described how I TRIED to generate the crash using backtracing. As said before I'm only able to reproduce the crash without using the terminal and the backtracing and starting Mixxx directly through the app shortcut.

[RJ Skerry-Ryan (rryan)]

Oh! Your final include path (Building with CXXFLAGS: ...) includes
-I/usr/local/opt/qt/include, which is going to use Homebrew's Qt5 install.

I wonder how that got on there? It isn't in your CFLAGS/CXXFLAGS, since
you're setting those manually. Maybe our Qt scons code is setting that
erroneously, but QTDIR is properly detected as /usr/local/Cellar/qt@4/4.8.
7_3.

On Mon, Apr 9, 2018 at 2:32 PM, RJ Skerry-Ryan <email address hidden> wrote:

> Do you always install Qt via homebrew or have you ever installed it via
> Qt's installer packages?
>
> Can you share the contents of /usr/local/bin ?
>
> FWIW, I don't install Homebrew to /usr/local, I install it to
> $HOME/.homebrew.
>
> On Mon, Apr 9, 2018 at 12:57 PM, Max Beiersdorfer <
> <email address hidden>> wrote:
>
>> Sorry for the late answer, I was on Easter holidays.
>>
>> @RJ Ryan: I already considered the workaround after my last post here
>> and got another error (last state before giving it up):
>>
>> Maximilians-MacBook-Air:mixxx DJMaxergy$ HOMEBREW_PATH=/usr/local
>> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
>> CFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus
>> -I/usr/local/include/opus -I/usr/local/opt/qt/include
>> -I/usr/local/opt/openssl/include"
>> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
>> CXXFLAGS="-I$HOMEBREW_PATH/include -I$HOMEBREW_PATH/include/opus
>> -I/usr/local/include/opus -I/usr/local/opt/qt/include
>> -I/usr/local/opt/openssl/include"
>> Maximilians-MacBook-Air:mixxx DJMaxergy$ export
>> LDFLAGS=-L$HOMEBREW_PATH/lib
>> Maximilians-MacBook-Air:mixxx DJMaxergy$ scons stdlib=libc++
>> scons: Reading SConscript files ...
>> INFO:root:Target Platform: osx
>> INFO:root:Target Machine: x86_64
>> INFO:root:Build: debug
>> INFO:root:Toolchain: gnu
>> INFO:root:Crosscompile: NO
>> INFO:root:Qt path: /usr/local/Cellar/qt@4/4.8.7_3
>> Automatically detecting Mac OS X SDK.
>> XCode developer directory:/Applications/Xcode.app/Contents/Developer
>> Found OS X SDK:macosx10.13
>> Automatically selected OS X SDK:/Applications/Xcode.app/Co
>> ntents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>> Checking whether the C++ compiler works... (cached) yes
>> Configuring MixxxCore
>> Configuring SoundTouch
>> Configuring ReplayGain
>> Configuring Ebur128Mit
>> Checking for C library ebur128... (cached) no
>> Checking for C library libebur128... (cached) no
>> Checking for C header file sys/queue.h... (cached) yes
>> Configuring PortAudio
>> Checking for C library portaudio... (cached) yes
>> Configuring PortMIDI
>> Checking for C library porttime... (cached) no
>> Checking for C library libporttime... (cached) no
>> Checking for C header file porttime.h... (cached) yes
>> Checking for C library portmidi... (cached) yes
>> Checking for C header file portmidi.h... (cached) yes
>> Configuring Qt
>> Configuring TestHeaders
>> Configuring FidLib
>> Configuring SndFile
>> Checking for C library sndfile... (cached) yes
>> Checking whether SFC_SET_COMPRESSION_LEVEL is declared... (cached) yes
>> Configuring FLAC
>> Checking for C header file FLAC/stream_decoder.h... (cached) yes
>> Checking for C library libFLAC... (cached) yes
>> Configuring OggVorb...

[RJ Skerry-Ryan (rryan)]

I'd love to get to the bottom of this, I agree it's pretty troubling. It would be great to know the status of this bug in 2.1.x and 2.2.x.

Max, would you be willing to try to reproduce using Mixxx 2.1.4 and Mixxx 2.2.0 beta?

http://downloads.mixxx.org/mixxx-2.1.4/mixxx-2.1.4-osxintel.dmg
http://downloads.mixxx.org/builds/2.2/release/mixxx-2.2.0-beta-2.2-release-macintel64-latest.dmg

No need to run using a debugger. If you get a crash, please just attach the macOS crash report found in ~/Library/Logs/DiagnosticReports/ or via the Console app. It would also help to have the mixxx.log from ~/Library/Application Support/Mixxx, but it's not crucial.

[RJ Skerry-Ryan (rryan)]

@Max, thanks so much for your testing so far. If you get the chance, it would be really helpful to see if the above two links (Mixxx 2.1.4 and 2.2.0 beta) crash. The mac crash report that they generate should have a useful backtrace in them, since those builds have debug symbols enabled.

[Be (be.ing)]

Considering the lack of response and this hasn't been replicated with 2.2, I'm removing the 2.2.0 milestone.

[Max Beiersdorfer (max-beiersdorfer)]

Sorry for the late response. I finally found time to test it using Mixxx 2.1.4 and Mixxx 2.2.0 beta and tested it several times in different constellations.

I was NOT able to reproduce a crash anymore!

BUT still...after a fresh boot of MacOS, a fresh start of Mixxx and after reconfiguring the sound settings from internal sound to the controller's sound card...I wasn't able to do scratching on touching a jog wheel of a playing deck for the first time. The track only stops/pauses at the touched position. After releasing and touching the jog wheel again I can scratch normally.
It's not that critical anymore but still annoying when you forget to touch the jog wheel once before you want to do some scratching.

[Daniel Schürmann (daschuer)]

Thank you for cinfiming.
Would you mind to file a new bug for this?

[Max Beiersdorfer (max-beiersdorfer)]

Ok, I reported a new bug for the scratching problem: http://bugs.launchpad.net/mixxx/+bug/1800343

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[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/9135