Hang when closing related to WinMM MIDI driver #3920

vwren · 2017-10-27T18:53:24Z

Configuration: Windows 7 SP1 32-bit, LMMS V1.2.0RC4, M-Audio MIDISport 2+2, driver version 6.1.3

When closing LMMS, a "zombie" LMMS process is left in the Task Manager which cannot be killed. These chew up about 40MB at a time. If LMMS is started and stopped repeatedly, more copies of the process will show up in the Task Manager. In testing, I found that changing the audio back-end to "Dummy" did not make a difference in this issue, but changing the MIDI back-end to "Dummy" enabled LMMS to close successfully. If I changed it back to WinMM, LMMS left a dead process running. There are no error messages displayed, and it leaves no entries in the Windows system logs.

I have other applications that I use with MIDI (OpenMPT, saVihoST, SimplePiano) which use the MIDISport 2+2 driver directly, and they don't seem to have any difficulty with my setup. I would be curious about other MIDI USB devices and WinMM, but I don't have any others to test. Anybody with USB keyboard controllers might want to have a look at your task manager!

michaelgregorius · 2017-10-29T12:45:52Z

I can confirm the findings. It looks like it might be related to the M-Audio MIDI drivers. I have two sound devices that I can use for testing:

M-Audio Audiophile 2496 (PCI card)
Behringer U-PHORIA UMC204 HD (USB audio interface)

During the tests I have varied what device is set as the default sound device in Windows 8.1 and the MIDI driver that's used by LMMS:

Default sound device	MIDI driver	Result
M-Audio	WinMM	Zombie processes
M-Audio	Dummy	Terminates correctly
Behringer	WinMM	Terminates correctly
Behringer	Dummy	Terminates correctly

Unfortunately I don't have the means to debug under Windows. Perhaps we can create a build that logs some info for LMMS' WinMM driver?

PhysSong · 2017-11-02T11:39:57Z

Then LMMS should hang in void MidiWinMM::closeDevices(). As far as I know, there are two possibilities if that's right:

Hang in Win32 API function for some reason
Stuck in while loop(less likely to be the issue)

vwren · 2017-11-14T03:02:46Z

I am not a programmer, but I wonder if this could be relevant (found on MSDN and related to WinMM and MIDI—even better, the person having the problem was using an M-Audio card). The symptoms certainly sound similar.

https://social.msdn.microsoft.com/Forums/en-US/091b793e-ce74-40fb-8a77-f99d9f4e3aa5/how-to-close-an-audio-device?forum=vbgeneral

tresf · 2017-11-14T03:17:19Z

@vwren thanks for the research and the hint. It appears we're attempting to call that in the MidiWinMM destructor: https://github.com/LMMS/lmms/blob/stable-1.2/src/core/midi/MidiWinMM.cpp#L253

The major difference is that the article you've posted closed by handle whereas we loop over all devices and close. Also, the Microsoft API says that problems can occur if buffers are still busy.

"If there are input buffers that have been sent by using the midiInAddBuffer function and have not been returned to the application, the close operation will fail. To return all pending buffers through the callback function, use the midiInReset function."

This likely exposes a leak, but to patch it we may benefit from calling midiInReset and then midiInClose.

zonkmachine · 2018-01-21T10:39:25Z

So something like:

	QMapIterator<HMIDIIN, QString> i( m_inputDevices );
	while( i.hasNext() )
	{
		midiInReset( i.next().key() );
		midiInClose( i.next().key() );
	}

vwren · 2018-01-21T17:30:49Z

This should also be done for midiOut, I'm thinking, to ensure that all buffers are freed before closing.

QMapIterator<HMIDIIN, QString> i( m_inputDevices );
while( i.hasNext() )
{
	midiInReset( i.next().key() );
	midiInClose( i.next().key() );
}

QMapIterator<HMIDIOUT, QString> o( m_outputDevices );
while( o.hasNext() )
{
	midiOutReset( o.next().key() );
	midiOutClose( o.next().key() );
}

zonkmachine · 2018-01-21T17:46:47Z

Yes.

PS. I'm not hacking this by the way. I'm not anywhere near a Windows computer.

PhysSong · 2018-03-20T00:29:48Z

Here are Windows 32-bit/64-bit executables with the patch:
https://github.com/PhysSong/lmms/releases/tag/v1.2.0-rc50 Deleted.

musikBear · 2018-03-20T14:50:00Z

@PhysSong i will install and see if i can get mem-leaks on win 32

musikBear · 2018-03-20T15:28:37Z

Closing down i get this every time

That is bad, but something new now occur.
Getting this crash message, has always meant that there will be orphan remoteVST.dll's, that is left as memory leaks, for every VST in the project.
There is none!
I have not seen this before.
I looks like lmms does shut down, but there is still a 'abnormality' that cast the win-error-popup.
There is also a LADSPA load problem

Is you build limited, because that could influence the shutdown-process imo.
...
Forgot to say that the win-error-popup comes even without any VSTs at all. An empty project, cast the win-error too.

PhysSong · 2018-03-20T15:42:45Z

@musikBear Thank you for testing. I'll test it and see if I can reproduce the crash.

michaelgregorius · 2018-03-20T16:07:05Z

@PhysSong Unfortunately I am still getting the hanging processes with your patched executables.

musikBear · 2018-03-21T13:23:18Z

@PhysSong i ran into even more issues. The test-release cant load all factory-instruments. Trying to load free-boy a not found error pop-up, and then the application crash completely. This time with orphans.
Again i ask you: Have you compiled all parts? Imo that is necessary, for this issue

zonkmachine · 2018-04-28T12:34:24Z

This should also be done for midiOut, I'm thinking, to ensure that all buffers are freed before closing.

Ardour stopped using midiOutReset() after getting hangs: Ardour/ardour@d10913e

vwren · 2018-05-04T15:24:56Z

It's possible that midiOutReset() is unstable. I know that SimplePiano uses the Reset/Close destructor for MIDI out, and for MIDI in, uses midiInStop(), midiInReset(), midiInClose(). I have never had it hang on me when closing, but it would take a larger sample size to have more confidence in it. (on further testing, I was wrong—the MIDI is unstable and it does hang, but the image is only 1.3MB and didn't cause much memory loss. So the destructor might be to blame)

Another issue might be caused by the Midi Stream manager. http://mastersonicarts.uniroma2.it/wp-content/uploads/2016/01/MIDI-Specification-11.pdf (search for "midiOutReset" and read the WARNING paragraph after it). I kind of doubt that Ardour is using the stream manager, but I have no evidence one way or the other. It would appear that midiOutReset() is useful mainly for shutting down stuck notes, so its function is not orthogonal to midiInReset() which frees up buffer space. I'm finding differing opinions, but there seems to be some consensus around the idea that midiOutReset() is broken and unnecessary, especially if there's another mechanism for handling stuck notes.

PhysSong · 2018-05-07T12:45:01Z

@vwren @michaelgregorius Here's a new build without midiOutReset(midiInReset only):
https://github.com/PhysSong/lmms/releases/tag/v1.2.0-rc51/

michaelgregorius · 2018-05-12T09:04:20Z

@PhysSong, with version RC51 I now get a crash when I close LMMS (but the process is gone 😉). Here's some more information:

Problemsignatur:
  Problemereignisname:	APPCRASH
  Anwendungsname:	lmms.exe
  Anwendungsversion:	0.0.0.0
  Anwendungszeitstempel:	adf0ade8
  Fehlermodulname:	Qt5Core.dll
  Fehlermodulversion:	5.4.2.0
  Fehlermodulzeitstempel:	00000020
  Ausnahmecode:	c0000005
  Ausnahmeoffset:	0000000000080cc0
  Betriebsystemversion:	6.3.9600.2.0.0.256.48
  Gebietsschema-ID:	1031
  Zusatzinformation 1:	6a60
  Zusatzinformation 2:	6a60f3846abeaee1799080a162c2d495
  Zusatzinformation 3:	f8b8
  Zusatzinformation 4:	f8b89ef7aa7e11afcf9615006ec5ac3d

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=280262

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
  C:\WINDOWS\system32\de-DE\erofflps.txt

PhysSong · 2018-05-31T14:41:38Z

I found that I did something wrong with iterators. I've fixed the iterator issue and created new builds.
@vwren @michaelgregorius New binaries available: https://github.com/PhysSong/lmms/releases/tag/v1.2.0-rc52

michaelgregorius · 2018-06-18T16:34:04Z

@PhysSong, I have installed the 64 bit version of LMMS 1.2.0-RC52 and I am still getting a crash when I close the application even if I do not switch to the M-Audio interface. Steps are:

Start LMMS 1.2.0-RC52.
Quit with CTRL+Q.

Additional info (does not look like it will help much though):

Problemsignatur:
  Problemereignisname:	APPCRASH
  Anwendungsname:	lmms.exe
  Anwendungsversion:	0.0.0.0
  Anwendungszeitstempel:	ade0add8
  Fehlermodulname:	lmms.exe
  Fehlermodulversion:	0.0.0.0
  Fehlermodulzeitstempel:	ade0add8
  Ausnahmecode:	c0000005
  Ausnahmeoffset:	00000000000a7db0
  Betriebsystemversion:	6.3.9600.2.0.0.256.48
  Gebietsschema-ID:	1031
  Zusatzinformation 1:	7560
  Zusatzinformation 2:	7560d411dbc17020b70fb50fb8691831
  Zusatzinformation 3:	4fe6
  Zusatzinformation 4:	4fe6b3f41321af4df47f57eb001c90d6

PhysSong · 2018-06-21T06:31:20Z

@michaelgregorius QMapIterator seems to behave somewhat strange, so I needed to work around it. Here's a new 64bit installer: lmms-1.2.0-rc6.14-win64.exe
I hope it will work this time.

michaelgregorius · 2018-06-21T17:02:15Z

@PhysSong With lmms-1.2.0-rc6.14-win64.exe the crashes are gone and I also do not get any hanging processes anymore when I close the application. Looks like we can close this issue. 👍 🎉

@vwren Can you please test with the latest RC if the issue is fixed for you as well?

PhysSong · 2018-06-21T20:54:00Z

I'll just upload 32bit binary and open a pull request. Good to hear that's working!

michaelgregorius mentioned this issue Oct 29, 2017

LMMS 1.1.90-win32-qt5 keeps running after the application has been closed #2774

Closed

PhysSong added the bug label Nov 18, 2017

zonkmachine added this to the 1.2.0 milestone Jan 21, 2018

zonkmachine added the windows label Feb 2, 2018

musikBear mentioned this issue Mar 20, 2018

VST-Instrument cross-dragging, crashes lmms #2086

Closed

PhysSong mentioned this issue Jun 25, 2018

Fix hang on exit when using specific MIDI devices on Windows #4451

Merged

PhysSong closed this as completed in #4451 Jun 26, 2018

arteme mentioned this issue Oct 12, 2022

Windows: closing pod-ui while downloading programs from PocketPOD leaves the app hanging arteme/pod-ui#12

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hang when closing related to WinMM MIDI driver #3920

Hang when closing related to WinMM MIDI driver #3920

vwren commented Oct 27, 2017 •

edited

Loading

michaelgregorius commented Oct 29, 2017

PhysSong commented Nov 2, 2017

vwren commented Nov 14, 2017

tresf commented Nov 14, 2017

zonkmachine commented Jan 21, 2018

vwren commented Jan 21, 2018 •

edited

Loading

zonkmachine commented Jan 21, 2018 •

edited

Loading

PhysSong commented Mar 20, 2018 •

edited

Loading

musikBear commented Mar 20, 2018

musikBear commented Mar 20, 2018 •

edited

Loading

PhysSong commented Mar 20, 2018

michaelgregorius commented Mar 20, 2018

musikBear commented Mar 21, 2018

zonkmachine commented Apr 28, 2018

vwren commented May 4, 2018 •

edited

Loading

PhysSong commented May 7, 2018

michaelgregorius commented May 12, 2018

PhysSong commented May 31, 2018

michaelgregorius commented Jun 18, 2018

PhysSong commented Jun 21, 2018

michaelgregorius commented Jun 21, 2018

PhysSong commented Jun 21, 2018

Hang when closing related to WinMM MIDI driver #3920

Hang when closing related to WinMM MIDI driver #3920

Comments

vwren commented Oct 27, 2017 • edited Loading

michaelgregorius commented Oct 29, 2017

PhysSong commented Nov 2, 2017

vwren commented Nov 14, 2017

tresf commented Nov 14, 2017

zonkmachine commented Jan 21, 2018

vwren commented Jan 21, 2018 • edited Loading

zonkmachine commented Jan 21, 2018 • edited Loading

PhysSong commented Mar 20, 2018 • edited Loading

musikBear commented Mar 20, 2018

musikBear commented Mar 20, 2018 • edited Loading

PhysSong commented Mar 20, 2018

michaelgregorius commented Mar 20, 2018

musikBear commented Mar 21, 2018

zonkmachine commented Apr 28, 2018

vwren commented May 4, 2018 • edited Loading

PhysSong commented May 7, 2018

michaelgregorius commented May 12, 2018

PhysSong commented May 31, 2018

michaelgregorius commented Jun 18, 2018

PhysSong commented Jun 21, 2018

michaelgregorius commented Jun 21, 2018

PhysSong commented Jun 21, 2018

vwren commented Oct 27, 2017 •

edited

Loading

vwren commented Jan 21, 2018 •

edited

Loading

zonkmachine commented Jan 21, 2018 •

edited

Loading

PhysSong commented Mar 20, 2018 •

edited

Loading

musikBear commented Mar 20, 2018 •

edited

Loading

vwren commented May 4, 2018 •

edited

Loading