WinXp crash master r5385 and 1.12 r5403 and --developer

Bug #1448630 reported by Daniel Schürmann
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Triaged
Medium
Unassigned

Bug Description

Mixxx crashes after the Skin is shown.

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

Without the --developer flag Mixxx does not crash
Attached the log a non crashing run.

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

Debug [Main]: Recordings folder set to "C:/Dokumente und Einstellungen/Besitzer/
Eigene Dateien/Eigene Musik/Mixxx/Recordings"
Debug [Main]: AnalysisLibraryTableModel(0x785d9008) select() took 0 ms 0
Debug [Main]: AnalysisLibraryTableModel(0x785d9008) select() took 0 ms 0
Debug [Main]: DlgAnalysis(0x7856e8c8, name = "DlgAnalysis") analysisActive false

Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[VinylCon
trol]" , "show_vinylcontrol" )
Warning [Main]: ControlDoublePrivate::getControl returning NULL for ( "[VinylCon
trol]" , "show_vinylcontrol" )
Debug [Main]: MixxxLibraryFeature::activate()
Debug [Main]: LibraryTableModel(0x265f0d58) select() took 0 ms 0
Debug [Main]: WSearchLineEdit::restoreSearch( "" )
Debug [Controller]: ControllerManager: Setting up devices
Debug [Controller]: Scanning PortMIDI devices:
Debug [Controller]: Found output device # 0 Microsoft MIDI-Mapper
Debug [Main]: Starting LibraryScanner thread.
Debug [Controller]: Found output device # 1 Microsoft GS Wavetable SW Synth
Debug [Controller]: Scanning HSS1394 devices:
Debug [Controller]: Nodes detected: 0
Debug [Controller]: Scanning HID devices:
[New Thread 1056.0x104]
[New Thread 1056.0xf44]
Debug [Main]: SoundManager::setupDevices()
Debug [Controller]: ControllerManager::getControllerList
Debug [Controller]: Controller polling stopped.
gdb: unknown target exception 0xe06d7363 at 0x7c812fd3

Program received signal ?, Unknown signal.
[Switching to Thread 1056.0xf44]
0x7c812fd3 in RaiseException () from C:\WINDOWS\system32\kernel32.dll
(gdb) thread backtrace all
No symbol table is loaded. Use the "file" command.
(gdb) bt
#0 0x7c812fd3 in RaiseException () from C:\WINDOWS\system32\kernel32.dll
#1 0x00a29339 in MSVCR120!_CxxThrowException ()
   from C:\WINDOWS\system32\msvcr120.dll
#2 0x00a6da6a in fcloseall () from C:\WINDOWS\system32\msvcr120.dll
#3 0x621efe30 in ?? ()
#4 0x006c1f21 in mixxx!??4RubberBandStretcher@RubberBand@@QAEAAV01@ABV01@@Z
    ()
#5 0x02000000 in ?? ()
#6 0x00451818 in mixxx!hid_error ()
#7 0x621efeec in ?? ()
#8 0x67026c70 in QtCore4!??_FQEventDispatcherWin32@@QAEXXZ ()
   from C:\Programme\Mixxx\QtCore4.dll
#9 0x0467bc88 in ?? ()
#10 0x00a3c001 in _get_tlsindex () from C:\WINDOWS\system32\msvcr120.dll
#11 0x0012fb24 in ?? ()
#12 0x7c80b729 in KERNEL32!GetModuleFileNameA ()
   from C:\WINDOWS\system32\kernel32.dll
#13 0x00000000 in ?? ()
(gdb)

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

Debug build:

[New Thread 3908.0xd30]
[New Thread 3908.0xe54]
[New Thread 3908.0x9ac]
[New Thread 3908.0xfb0]
gdb: unknown target exception 0xe06d7363 at 0x7c812fd3

Program received signal ?, Unknown signal.
[Switching to Thread 3908.0x324]
0x7c812fd3 in RaiseException () from C:\WINDOWS\system32\kernel32.dll
(gdb) thread backtrace all
No symbol table is loaded. Use the "file" command.
(gdb) bt
#0 0x7c812fd3 in RaiseException () from C:\WINDOWS\system32\kernel32.dll
#1 0x00fe0b86 in MSVCR120D!_CxxThrowException ()
   from C:\Programme\Mixxx\msvcr120d.dll
#2 0x00fec2a1 in MSVCR120D!??2@YAPAXI@Z ()
   from C:\Programme\Mixxx\msvcr120d.dll
#3 0x00fec35d in MSVCR120D!??_U@YAPAXI@Z ()
   from C:\Programme\Mixxx\msvcr120d.dll
#4 0x00998f8c in mixxx!hid_exit ()
#5 0x00997024 in mixxx!hid_exit ()
#6 0x00997a99 in mixxx!hid_exit ()
#7 0x009975a1 in mixxx!hid_exit ()
#8 0x00993ece in mixxx!hid_exit ()
#9 0x00549b0b in mixxx!hid_exit ()
#10 0x0054ad8e in mixxx!hid_exit ()
#11 0x00549f5d in mixxx!hid_exit ()
#12 0x00547e30 in mixxx!hid_exit ()
#13 0x00851251 in mixxx!hid_exit ()
#14 0x6707383f in QtCored4!??_4QRectF@@QAEAAV0@ABV0@@Z ()
   from C:\Programme\Mixxx\QtCored4.dll
#15 0x00f23651 in beginthreadex () from C:\Programme\Mixxx\msvcr120d.dll
#16 0x00f23861 in endthreadex () from C:\Programme\Mixxx\msvcr120d.dll
#17 0x7c80b729 in KERNEL32!GetModuleFileNameA ()
   from C:\WINDOWS\system32\kernel32.dll
#18 0x00000000 in ?? ()
(gdb) bt all
No symbol table is loaded. Use the "file" command.
(gdb)

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

The 1.12 branch 5377 is not effected. This is interesting, because the difference it mainly the new soundsource.
But it crashes before Mixxx has the chance to touch a file. And why does the --developer flag makes a difference.

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

Why are the backtraces so different. Shomething really bad is going on.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Download full text (37.7 KiB)

Did you do a clean rebuild after switching branches? Might help.

I did a quick analysis on Fedora 21 x86_64 with valgrind and the --developer option, but can't spot any warnings related to a SoundSource!?

But what I see are many "Conditional jump or move depends on uninitialised value(s)" warnings for SkinContext::SkinContext(SkinContext const&):

==19942== Conditional jump or move depends on uninitialised value(s)
==19942== by 0x79AD983: ??? (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0x79B8042: QScriptValue::setProperty(QString const&, QScriptValue const&, QFlags<QScriptValue::PropertyFlag> const&) (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0xB470DD: SkinContext::SkinContext(SkinContext const&) (skincontext.cpp:49)
==19942== by 0xB41275: LegacySkinParser::parseTemplate(QDomElement) (legacyskinparser.cpp:1434)
==19942== by 0xB3EEDF: LegacySkinParser::parseNode(QDomElement) (legacyskinparser.cpp:522)
==19942==
==19942== Conditional jump or move depends on uninitialised value(s)
==19942== by 0x79AD983: ??? (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0x79B8042: QScriptValue::setProperty(QString const&, QScriptValue const&, QFlags<QScriptValue::PropertyFlag> const&) (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0xB470DD: SkinContext::SkinContext(SkinContext const&) (skincontext.cpp:49)
==19942== by 0xB41275: LegacySkinParser::parseTemplate(QDomElement) (legacyskinparser.cpp:1434)
==19942== by 0xB3EEDF: LegacySkinParser::parseNode(QDomElement) (legacyskinparser.cpp:522)
==19942==
==19942== Conditional jump or move depends on uninitialised value(s)
==19942== by 0x79AD983: ??? (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0x79B8042: QScriptValue::setProperty(QString const&, QScriptValue const&, QFlags<QScriptValue::PropertyFlag> const&) (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0xB470DD: SkinContext::SkinContext(SkinContext const&) (skincontext.cpp:49)
==19942== by 0xB41275: LegacySkinParser::parseTemplate(QDomElement) (legacyskinparser.cpp:1434)
==19942== by 0xB3EEDF: LegacySkinParser::parseNode(QDomElement) (legacyskinparser.cpp:522)
==19942==
==19942== Conditional jump or move depends on uninitialised value(s)
==19942== by 0x79AD983: ??? (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0x79B8042: QScriptValue::setProperty(QString const&, QScriptValue const&, QFlags<QScriptValue::PropertyFlag> const&) (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0xB470DD: SkinContext::SkinContext(SkinContext const&) (skincontext.cpp:49)
==19942== by 0xB41275: LegacySkinParser::parseTemplate(QDomElement) (legacyskinparser.cpp:1434)
==19942== by 0xB3EEDF: LegacySkinParser::parseNode(QDomElement) (legacyskinparser.cpp:522)
==19942==
==19942== Use of uninitialised value of size 8
==19942== by 0x79AD983: ??? (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0x79B8042: QScriptValue::setProperty(QString const&, QScriptValue const&, QFlags<QScriptValue::PropertyFlag> const&) (in /usr/lib64/libQtScript.so.4.8.6)
==19942== by 0xB470DD: SkinContext::SkinContext(SkinContext const&) (skincontext.cpp:49)
==19942== by 0xB41275: LegacySkinParser::parseTemplate(Q...

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

Thank you for the valgrind log. It seams to be some homework open :-/

All binaries are from downloads.mixxx.org/builds.

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

git5403 is still effected.

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

Can one else reproduce the crash?

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

I cannot reproduce an a different XP

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

Mixxx crashes because of an unhandled C++ exception (0xE06D7363)
http://blogs.msdn.com/b/oldnewthing/archive/2010/07/30/10044061.aspx

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

Backtarce of Mixxx 1.12 beta debug git5403 1.12 branch (NOT MASTER)

(gdb) bt
#0 0x7c812fd3 in RaiseException () from C:\WINDOWS\system32\kernel32.dll
#1 0x00fd0b86 in MSVCR120D!_CxxThrowException ()
   from C:\Programme\Mixxx\msvcr120d.dll
#2 0x00fdc2a1 in MSVCR120D!??2@YAPAXI@Z ()
   from C:\Programme\Mixxx\msvcr120d.dll
#3 0x00fdc35d in MSVCR120D!??_U@YAPAXI@Z ()
   from C:\Programme\Mixxx\msvcr120d.dll
#4 0x0098e18c in mixxx!hid_exit ()
#5 0x0098c224 in mixxx!hid_exit ()
#6 0x0098cc99 in mixxx!hid_exit ()
#7 0x0098c7a1 in mixxx!hid_exit ()
#8 0x009890ce in mixxx!hid_exit ()
#9 0x0054822b in mixxx!hid_exit ()
#10 0x005492de in mixxx!hid_exit ()
#11 0x0054862d in mixxx!hid_exit ()
#12 0x009488e3 in mixxx!hid_exit ()
#13 0x00947a49 in mixxx!hid_exit ()
#14 0x00947e4f in mixxx!hid_exit ()
#15 0x1000b677 in portaudio!PaWasapi_ThreadPriorityRevert ()
   from C:\Programme\Mixxx\portaudio.dll
#16 0x00000000 in ?? ()

Changed in mixxx:
importance: Undecided → Critical
milestone: none → 1.12.0
summary: - WinXp crash git master r5385
+ WinXp crash master r5385 and 1.12 r5403
Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: WinXp crash master r5385 and 1.12 r5403

If that backtrace is to be believed then this is the only method called:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681961(v=vs.85).aspx
which doesn't mention any possibility of throwing.

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

have you tried the debug diagnostic tool?
http://mixxx.org/wiki/doku.php/reporting_bugs#windows
that might shed some light

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

Tried the Debug And Diagostic Tool but with no success. Do not know what to do.

But I have noticed an other thing Mixxx consumes up to 2 GB Ram before it crashes.
Without --developer it starts much faster, and does not consumes that much memory.
1.12 5377 is not effected
1.12 5387 is not effected
1.12 5403 is effected
master r5385 is effected

I have done two installation cycles to though out random effects.

the first boot up pause happens here:
Debug [Main]: AnalyserWaveform::AnalyserWaveform()
Debug [Main]: Setting VAMP_PATH to: "C:\Programme\Mixxx\plugi
Debug [Main]: Creating ControllerManager
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Extension ".bulk.xml" total 1 presets
Debug [Main]: Extension ".hid.xml" total 9 presets
Debug [Main]: Extension ".midi.xml" total 85 presets
Debug [Main]: slotSetRateRange 1 0.08
Debug [Main]: slotSetRateRange 1 0.08
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
Debug [Main]: Loading resources from "C:/Programme/Mixxx/"
-> Here <-

The second one here:
 "LibraryScanner 1") "LIBRARY_SCANNER"
Debug [Main]: Requested sample rate: 48000 Hz, latency: 85.3333 ms
Debug [LibraryScanner 1]: DirectoryDAO::initialize LibraryScanner(0x6
me = "LibraryScanner 1") "LIBRARY_SCANNER"
Debug [Main]: Output channels: 2 | Input channels: 0
Debug [LibraryScanner 1]: LibraryScanner event loop starting.
Debug [Main]: Opening stream with id 6
DirectSound host buffer size frames: 8240, polling period seconds: 0.
r: 48000.000000
InitOutputBuffer() returns 0
Debug [Main]: Opened PortAudio stream successfully... starting
PaHost_ClearOutputBuffer: IDirectSoundBuffer_SetCurrentPosition retur
PaHost_StartOutput: IDirectSoundBuffer_Play returned = 0x0.
Debug [Main]: PortAudio: Started stream successfully
Debug [Main]: Actual sample rate: 48000 Hz, latency: 86.3333 ms
-> Here <-

Revision history for this message
Owen Williams (ywwg) wrote :

Try using git bisect to narrow down the exact breaking commit

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

I have no Windows build environment. Does anyone else with a windows build environment experience the crash?

Since it happens in master and 1.12 and it started after the fork but there is not much in common and it only happens with the --developers flag ... It could also be also a build server issue.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1448630] Re: WinXp crash master r5385 and 1.12 r5403

Do you totally delete c:\Programme\Mixxx each time?

Is it possible that there are some release DLLs left over in there?

On Wed, Apr 29, 2015 at 3:58 PM, Owen Williams <email address hidden> wrote:

> Try using git bisect to narrow down the exact breaking commit
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1448630
>
> Title:
> WinXp crash master r5385 and 1.12 r5403
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1448630/+subscriptions
>

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

The build server 1.12 and master build environments are the exact same
files -- so the only difference between a debug build on master vs 1.12 is
the code.

On Wed, Apr 29, 2015 at 4:20 PM, Daniel Schürmann <
<email address hidden>> wrote:

> I have no Windows build environment. Does anyone else with a windows
> build environment experience the crash?
>
> Since it happens in master and 1.12 and it started after the fork but
> there is not much in common and it only happens with the --developers
> flag ... It could also be also a build server issue.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1448630
>
> Title:
> WinXp crash master r5385 and 1.12 r5403
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1448630/+subscriptions
>

Revision history for this message
Daniel Schürmann (daschuer) wrote : Re: WinXp crash master r5385 and 1.12 r5403

> Do you totally delete c:\Programme\Mixxx each time?

No. I did it just now and installed 1.12 5403 still crashing.

> The build server 1.12 and master build environments are the exact same
files

Maybe a hint. Was the environment changed between 1.12 5387 and 1.12 5403?
Maybe a test would be nice to build 5387 with the current environment.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1448630] Re: WinXp crash master r5385 and 1.12 r5403

Hm. No change has happened in the debug environments at all for months.

The only change was that I re-built the release environments. I did this on
2015-04-21 when I sent this message:
http://sourceforge.net/p/mixxx/mailman/message/33934187/

On Wed, Apr 29, 2015 at 5:07 PM, Daniel Schürmann <
<email address hidden>> wrote:

> > Do you totally delete c:\Programme\Mixxx each time?
>
> No. I did it just now and installed 1.12 5403 still crashing.
>
> > The build server 1.12 and master build environments are the exact same
> files
>
> Maybe a hint. Was the environment changed between 1.12 5387 and 1.12 5403?
> Maybe a test would be nice to build 5387 with the current environment.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1448630
>
> Title:
> WinXp crash master r5385 and 1.12 r5403
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1448630/+subscriptions
>

Revision history for this message
Daniel Schürmann (daschuer) wrote : Re: WinXp crash master r5385 and 1.12 r5403

Ok, 1.12 5387 is not effected and was build on 24-Apr. So it was already build on the new environment.

On the other hand, the crash started after we have forked 1.12 on both branches and the most recent common commit is
https://github.com/mixxxdj/mixxx/commit/4e932b7c53979209268d09fcf7803c2ad377487c
Autor: RJ Ryan <email address hidden> 2015-04-23 01:26:54
Which is not effected.

So what append? :-/

Do you see any suspicious commit between 1.12 5387 and 1.12 5403?
Can you build a version between them? Maybe we can narrow the error.

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

I can reproduce the crash now on my other XP system if I use the same skin like on the other system: Deere.
If I start with on of the other skins, Mixxx does not crash. Swithing to Deere after Mixxx has started works as well.

I have noticed also that LateNight and Deere are eating slowly memory when stated in --developer mode
100 k / s. This does not happen when started without the flag.
Shade is not effected.
Is there an issue with SVG drawings? Maybe Uwes finding (comment #7) is on the right track.

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

Good news = Bad news
The crash and the memory leak is gone with 1.12 r5442

Instead I suffer now this:
https://bugs.launchpad.net/mixxx/+bug/1454649

Has the bad thing just moved?
This is an indicator of a real bad issue.

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

The crash is gone the memory leaking is slowed down with 1.12 r5442

In addition I suffer now this:
https://bugs.launchpad.net/mixxx/+bug/1454649

Has the bad thing moved?
This is an indicator of a real bad issue.

There is still a connection: --developer = leak
no developer = not leak.

Can anyone else confirm or not confirm this? We should get a feeling how common this problem is.

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

Ok: I have a hint: Now Shade is leaking as well-
I have recently switched to Open Sans.
Still need to verify if this depends?

So fixing Bug #1454649 will fix this?

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

I have just removed the "font" folder -> no leaking
restored folder -> leaking starts

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

The latest issues can also be reproduced on Win10
--developer flag = leaking

Revision history for this message
shalty (neogeo-dc) wrote :

I have been testing r5442 on a w7 x86, and it doesn't leak any of the skins i have tested (late night, deere, shade) with default configuration (except software waveforms because of the usual intel driver opengl crash), with autodj for some hour each, and the --developer option activated, of course.
They all consume between 800-1200, after some time doesn't grow anymore.

Note: about the traces, a process on windows can only use (without special flags on the .exe) 2gb of ram, so when it reaches the limit, can fail almost anywhere. And using valgrind is fine for the majority of the code, but not for #ifdef WIN32 code...

Revision history for this message
kramer (default-kramer) wrote :

On Win7, using the master branch. Specifically, this version: https://github.com/mixxxdj/mixxx/tree/b3275637200dc7e208d533d3cd005d1370dc9369

Problems only happen when using the --developer option. Sometimes I get a crash as soon as the skin shows. Other times it doesn't crash, but waveforms do not show up and almost every track fails to play with this output:

Warning [CachingReaderWorker 2]: Unrecoverable MP3 header decoding error: invalid (null) buffer pointer
Warning [CachingReaderWorker 2]: Unrecoverable MP3 header error: invalid (null) buffer pointer

And then it will crash later on. If the VS debugger can be trusted, here is a stack trace of the crashing thread:

  atioglxx.dll!695f2860()
  [Frames below may be incorrect and/or missing, no symbols loaded for atioglxx.dll]
> QtOpenGLd4.dll!QGLContextPrivate::setVertexAttribArrayEnabled(int arrayIndex, bool enabled) Line 2139 C++
  0000bc80()

And "arrayIndex" is -1949237504 in this case.

I didn't notice any problems with 1.12, but I didn't use the --developer option often.

Revision history for this message
Owen Williams (ywwg) wrote :

is this still happening? we haven't had reports of straight-up skin crashes in a while

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

Yes, the --developer flag leaking still persists.
It was recently reported here https://bugs.launchpad.net/mixxx/+bug/1495317
A solution is proposed in
https://github.com/mixxxdj/mixxx/pull/600

Changed in mixxx:
status: New → Confirmed
assignee: nobody → Daniel Schürmann (daschuer)
Revision history for this message
Owen Williams (ywwg) wrote :

crashes with --developer are not ideal but not critical. (Could be high, I guess)

summary: - WinXp crash master r5385 and 1.12 r5403
+ WinXp crash master r5385 and 1.12 r5403 and --developer
Changed in mixxx:
importance: Critical → Medium
Changed in mixxx:
status: Confirmed → In Progress
RJ Skerry-Ryan (rryan)
Changed in mixxx:
importance: Medium → Critical
importance: Critical → Medium
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Due to lack of progress, marking Triaged and clearing assignee. Feel free to revert if it is in fact still in progress :).

Changed in mixxx:
assignee: Daniel Schürmann (daschuer) → nobody
status: In Progress → Triaged
Changed in mixxx:
milestone: 2.0.0 → none
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/7987

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.

Other bug subscribers

Remote bug watches

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