-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when closing #2633
Comments
Came across this comment while working on another bug. May be related to the crash: #2339 (comment) |
Trying this on Linux, I get a crash when closing with DummyAudio in line |
Changing title as this affects multiple OSs. |
Although this was automatically closed by #2793... when testing an unrelated PR which included this commit, Mac still had a hard crash when closing. Reopening. Someone with a Mac, please provide a backtrace with latest master. If not, it'll have to wait for me to provide one. |
@tresf I can probably get a backtrace for this. Is there a debug build straight from master available anywhere (is there CI in place?)? |
Here's the stacktrace from Mac OS' (10.11.6) crash reporter when running with the dummy audio interface:
Is that what you were looking for? |
Sorry if I am calling out somethings that is known, but this topic is a little confusing. |
Yes we are aware, thank you. We believe the Windows issue to be resolved, but we can track it here if it resurfaces in RC2. |
I still get it about 20% of the time closing LMMS on MacOS |
@tresf .. darn. |
Since no linux reports came in so far, let me assist. I'm not a particularly heavy-duty user, but since coming across this issue, I've been paying attention to the behavior of 1.2, especially upon exit. I haven't experienced any crashes in regular usage (without a MIDI controller in use). Quitting the program after letting it sit idle for a while works fine, as does quitting during playback of a 18-track project. So I assume that there aren't any particularly nasty memory leaks or cleanup issues around. Addendum, since it was just mentioned in Discord: |
@irrenhaus3 that's a good theory however as the creator of this bug report and a Mac user, I can confirm this still happens rather frequently and Mac doesn't support VST yet. Since the crash logs specify |
Crash logs from 1.2.0-rc3. Rendering wasn't performed this time around.
|
Ok... I was having a hard time reproducing this until I closed it from the taskbar. Perhaps this sheds some light. Closing it from the "X" in the upper left wasn't causing the crash to occur.
|
I also get this backtrace occasionally. The
|
Using 1.2.0-RC4, I get a zombie process every time I close and re-start LMMS on the WIN32 version (W7). There's no errors displayed—just a process in the task manager that can't be killed. I first noticed it because if I do a save then quit before the "File was saved" message box closes, that message box will not leave the desktop EVER (at least until reboot). This seems to happen no matter what audio back-end I'm using (even dummy). I don't know enough about compiling on PCs to build a debugging version (if such even works). The task manager gives me the option of doing a core dump, but I have no idea if that would be in any way useful. (UPDATE: I thought it might have been because I had an ASIO version of libportaudio-2, but I changed it back to the default installed version and it made no difference). |
@vwren have you tried to shut completely down -not sleep, and then restart? |
@musikBear a full S5 restart is the way I've been getting rid of the zombie processes, though logging my user off should technically be enough to dump all processes running under my username (I haven't tried it). I get this first thing in the morning, which is an S5+G3 restart (I don't use Sleep or Hibernate) Since you're not having a problem, (Albeit XP is essentially Windows NT, where Windows 7/Vista is quite a bit different under the hood), I wanted to be sure there was nothing left over from my 1.1.3 install, so I uninstalled RC4, deleted the Program Files\LMMS directory (I noticed that uninstall leaves behind the QT5 dlls), rebooted, and reinstalled RC4 from scratch. It's still leaving zombies. The only other thing I can think to do is go through the Registry and delete all trace of LMMS before reinstalling, because I noticed that the new install retains the 1.1.3 file paths (not a great upgrade path from 1.1.3 if Registry cleaning is necessary). I am shutting down LMMS by hitting the "X" button, but using the File/Quit menu does the same thing. I also deleted the few VST plugins that I added, all from the "safe" list (even though there are no VST instruments active). Still getting zombies. Weird if I'm the only one, but since it gives no error messages, more people might be getting them and never know it if they don't check the task manager. |
@vwren does this occur when you use DummyAudio as the backend? This may be a separate issue and I recommend we track it as such. That said, we need someone to reproduce on similar OS and hardware. I don't mean to sound like a broken record, but if you're running an SSD, scan it for errors, worn bits can cause the strangest of problems with Windows processes and it happens on two of my machines semi-annually. |
I wanted to make sure I was running clean, so I wiped everything off, including any registry mentions of LMMS, and installed 1.2.0RC4 from scratch. I think this is a driver-related issue. Interestingly enough, it's not sound-related. If I put the audio to dummy, it still hangs. If I point the MIDI to dummy, however, it does not hang. I'm using an M-Audio MIDISport 2+2 (the original ugly green one). The only options in the drop-down are Dummy and WinMM. I'm going to try upgrading the MIDISport driver from 6.1.2 to 6.1.3 (the last available) UPDATE: Nope. Going to 6.1.3 makes no difference. It's a problem with WinMM. |
In relation to the "crash on close" issue in general, I recently noticed the following recommendation in the
It would appear LMMS doesn't currently follow this advice: Lines 966 to 980 in 9d317e1
Could be worth trying out the (I don't know if any of the code that appears after |
May only happen with DummyAudio, but no user-way to change it, since closing it crashes and the
~.lmmsrc.xml
file never gets written, so I consider this critical as it potentially makes master branch unusable on Mac to the average user.Mixer.cpp#L214:L228
AudioDummy.h#L88
I haven't provided a stack trace because I feel the OS provided one has enough information to investigate this.Edit: Switching audio device to
PortAudio/CoreAudio
causes the crash to occur in a different place with a different backtrace, so this may not be specifically related tostopProcessing
but rather to somefree()
memory call somewhere. A full backtrace is most likely needed here for proper investigation.Apple provided crash report:
The text was updated successfully, but these errors were encountered: