Mixxx doesn't exit cleanly (cmetrics?)

Bug #235479 reported by Ronin
6
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
High
Unassigned
1.6
Invalid
Undecided
Unassigned

Bug Description

On WinXP 32bit with MIXXX 1.6 betas

setting the input controller device appropriate works fine. reopening MIXXX results in the device setting being resetted to the first one if there is more than one device. you have to set the control device everytime you start up.

Revision history for this message
Albert Santoni (gamegod) wrote :

http://mixxx.org/forums/viewtopic.php?f=3&t=103

groovelastig on the forums confirmed this, but he also mentioned that vinyl control is checked every time he starts Mixxx. Together, these are telling me that Mixxx isn't exiting cleanly on Win32.

It looks like Beta3 isn't exiting cleanly on my Linux machine because of cmetrics:

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb57da760 (LWP 18605)]
0xb7fdf410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdf410 in __kernel_vsyscall ()
#1 0xb70708eb in waitpid () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08230271 in cm_close (timeout=10) at lib/cmetrics/lindriver.cpp:266
#3 0x0810986c in ~MixxxApp (this=0x8418188) at src/mixxx.cpp:483
#4 0x080f2eac in main (argc=1, argv=0xbfd6d3a4) at src/main.cpp:220

Changed in mixxx:
assignee: nobody → who8877
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Albert Santoni (gamegod) wrote :
Download full text (3.1 KiB)

Full backtrace from above, and important note at bottom:

(gdb) thread apply all bt

Thread 8 (Thread 0xb0682b90 (LWP 18625)):
#0 0xb7fdf410 in __kernel_vsyscall ()
#1 0xb6c4dc07 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0x081e2546 in MidiObjectALSASeq::run (this=0x86fe548) at src/midiobjectalsaseq.cpp:255
#3 0xb72b3057 in ?? () from /usr/lib/libQtCore.so.4
#4 0xb70684fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb6c57e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 7 (Thread 0xb0e83b90 (LWP 18624)):
#0 0xb7fdf410 in __kernel_vsyscall ()
#1 0xb706caa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb72b3924 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#3 0x0818f2b3 in BpmDetector::run (this=0x84fae80) at src/bpmdetector.cpp:127
#4 0xb72b3057 in ?? () from /usr/lib/libQtCore.so.4
#5 0xb70684fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb6c57e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread 0xb1684b90 (LWP 18623)):
#0 0xb7fdf410 in __kernel_vsyscall ()
#1 0xb706caa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb72b3924 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#3 0x0818d185 in WaveSummary::run (this=0xfffffe00) at src/wavesummary.cpp:81
#4 0xb72b3057 in ?? () from /usr/lib/libQtCore.so.4
#5 0xb70684fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb6c57e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (Thread 0xb1e85b90 (LWP 18621)):
#0 0xb734bde0 in ?? () from /usr/lib/libQtCore.so.4
#1 0xb72b3057 in ?? () from /usr/lib/libQtCore.so.4
#2 0xb70684fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb6c57e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb57da760 (LWP 18605)):
#0 0xb7fdf410 in __kernel_vsyscall ()
---Type <return> to continue, or q <return> to quit---
#1 0xb70708eb in waitpid () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08230271 in cm_close (timeout=10) at lib/cmetrics/lindriver.cpp:266
#3 0x0810986c in ~MixxxApp (this=0x8418188) at src/mixxx.cpp:483
#4 0x080f2eac in main (argc=1, argv=0xbfd6d3a4) at src/main.cpp:220
======

Mixxx's output:
Debug: Destroying MixxxApp
Debug: Write track xml, 0
Debug: close soundmanager 330
Debug: SoundManager::closeDevices()
[Thread 0xad90ab90 (LWP 18686) exited]
Debug: soundmanager->close() done
Debug: delete soundmanager, 379
Debug: SoundManager::clearDeviceList()
Debug: SoundManager::closeDevices()
Debug: delete master, 380
Debug: in ~EngineMaster()
Debug: delete channel1, 381
Debug: delete channel2, 381
Debug: delete buffer1, 382
Debug: delete buffer2, 395
Debug: delete view, 397
[Thread 0xb42d2b90 (LWP 18666) exited]
[Thread 0xb4ff2b90 (LWP 18665) exited]
[Thread 0xb3375b90 (LWP 18667) exited]
[Thread 0xae11ab90 (LWP 18685) exited]
[Thread 0xafe14b90 (LWP 18684) exited]
Debug: delete tracks, 465
Debug: save config, 474
Debug: delete config, 476

(hangs here... see note below)

======

Important Note:
If I exit and just don't touch it, it'll eventually timeout and say:
   Program terminated with signal SIG...

Read more...

Revision history for this message
Jayson (muzzik101) wrote :

Not sure if this will help, but this was a problem I noticed with the 1.6 beta 2 and it's still there in th 1.6 beta 3:

On Windows XP SP2, whenever I close/exit Mixxx, if I open the task manager and look at open applications, Mixxx is not listed. But If I view running processes, Mixxx.exe is still running. When I try to end the process, it will not end.

If I re-open Mixxx and close/exit another Mixxx.exe process is left running. I have seen as many as 5 Mixxx.exe processes running at once after opening and closing the program multiple times. The only way for me to end all of the processes is to re-boot.

Revision history for this message
Jayson (muzzik101) wrote :

I did some testing and found that the Mixxx.exe process only stays open on exit if a MIDI device is connected. Here is a screenshot of my running processes.

Revision history for this message
Albert Santoni (gamegod) wrote :

Jayson: I've built a new win32 package using today's SVN, and it's compiled without CMetrics support. I suspect this may be causing your hangs.
The new package is here: http://downloads.mixxx.org/mixxx-1.6.0-svn/mixxx-1.6.0-svn06212008-win.exe

Please test this and let us know if this problem still occurs. Your testing has been very useful in tracking down this bug thus far. :)

Thanks!

Revision history for this message
Jayson (muzzik101) wrote :

Hi Albert, thanks for your help.

I installed the new win32 Mixxx package and I have been doing some testing. When I run Mixxx with a MIDI controller connected, then exit Mixx, a Mixxx.exe process is is still left running (same as with the 1.6 beta 3). Now, with the new package, if I restart Mixxx while a Mixxx.exe process is still running, Mixxx crashes.

Maybe this could be a problem related to my MIDI controller? I'm using the M-AUDIO Trigger Finger. Everything else about Mixxx has been great and other than this problem, Mixxx has been working really well for me. Let me know if there is anything else I can do to help.

Revision history for this message
Albert Santoni (gamegod) wrote :

Jayson: I'm still stumped here, but I'd like to put more time into this bug.

What happens if you unplug your MIDI controller before running Mixxx and then close Mixxx?

Make sure you wait at least 30 seconds before checking the process list to see if Mixxx.exe is gone.

Also, can you check to see if this bug still occurs with Beta 4?
http://downloads.mixxx.org/mixxx-1.6.0-beta4/mixxx-1.6.0-beta4-win.exe

Thanks,
Albert

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

Please test in Mixxx 1.6.1. If we don't hear back from you in 7 days, we will close this bug.

Changed in mixxx:
assignee: who8877 → nobody
Changed in mixxx:
status: Confirmed → Fix Committed
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
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/4969

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.