Lmms: Opening mmpz from within zip file crashes LMMS

[repsej]

Double clicking a zipped project results in this:

edit: To be more specific: this is about double clicking the file inside a zip package (so, first open the zip file and then double click the containing project to reproduce).

[repsej]

Sorry for the danish text ... it reads:

"Microsoft Management Console has stopped working"

etc. etc.

[DeRobyJ]

It doesn't work on windows 7 64 bit either.
By the way, it's not much of a problem: mmpz are altready a zipped format, and by zipping them you only save 5% of their tens of KB.

When sharing a zip with a lot of different projects, just warn the receiver.

[Umcaruje]

Well, its much better to extract the file from an archive before opening it. OTOH, I think windows actually extracts the file you opened into its tmp folder, and then just opens it from there, so this could be a permissions issue.

[tresf]

By the way, it's not much of a problem: mmpz are altready a zipped format, and by zipping them you only save 5% of their tens of KB.

FYI, mmpz are not zipped format in the sense ZIP ~= .ZIP, a Windows compression format.

[tresf]

Double clicking a zipped project results in [crash]

Yes, because you told Windows to open that file with LMMS. This is not a bug. Perhaps we can handle decoding/crash exceptions better, but that is an enhancement, if it is even worth our time.

[tresf]

Double clicking a zipped project results in [crash]

Wait a second... did you double click the zip, or double-click the mmpz inside the zip? Your screenshot suggests the latter. These are entirely different things. If we can't open a file inside a zip, that's a completely different issue (and probably a wont-fix).

[repsej]

I double clicked a mmpz file inside a zip :) (edited text to be more specific)

[musikBear]

fyi
I have no issues at all opening either a mmp or a mmpz inside a zipped folder:

The displayed folder is a std winZipped folder with both a mmp and a mmpz
Both opens farst and reliable.

[softrabbit]

I tried this on Windows Vista 32-bit, using the latest stable LMMS. Looking in the task manager, I could see an LMMS process started with a project file in the path C:\Users\username\AppData\Local\Temp\Temp1_lb302-bug.zip\lb302-bug.mmpz (no spaces or anything).

LMMS showed the splash screen for a couple of minutes, meanwhile I navigated to the directory and confirmed that the file existed. The LMMS process hung around without a window after the splash was gone, so I terminated it after a few more minutes. When I then double-clicked on that same temporary file after the first LMMS instance was gone, it opened perfectly. I couldn't see any difference in the command lines.

[tresf]

I double clicked a mmpz file inside a zip :) (edited text to be more specific)

Thanks for clarification. I can confirm this crashes LMMS. On Windows 10, this prompts to install DirectPlay. (don't, BTW)

Looking in the task manager, I could see an LMMS process started with a project file in the path

Yeah, it seems that the path is correct, but the working directory is not... Not sure what part of the launcher this would break...

Here's a test that will work with Windows XP and higher...

test.js (a cscript.exe associated script)

WScript.Echo("Current Directory: " + WScript.CreateObject("WScript.Shell").CurrentDirectory);
WScript.Echo("This File: " + WScript.ScriptFullName);

1. Create file and test it by double-clicking it.
2. Notice the paths are correct.
3. Now zip this file and launch it from within the Zip
4. Notice the current directory is C:\Windows\System32

So this crash is likely to be caused by something we're assuming about the working path/current directory. The good part is that means we might be able to fix it.

On a side note, we don't recommend EVER making changes to a zip file and expect the changes to be saved, so this "bug" may very well be considered a failsafe from a WHERE DID MY PROJECT CHANGES GO perspective (albeit a poor experience).

-Tres

[tresf]

@musikBear

I have no issues at all opening either a mmp or a mmpz inside a zipped folder:

Stop using XP.

[musikBear]

Stop using XP.

it (xp) beat both w10 and wVista _this_ time :P

Stop using XP.

i ought to but i was not getting an otherwise promised goodiebag, so ..

[tresf]

it (xp) beat both w10 and wVista this time :P

A broken clock is correct twice a day, will you defend that too? :smile:

Back on topic... I think we have enough information to investigate this bug and at least make the user experience better. :+1:

[PhysSong]

@tresf's old finding helped me finding the cause of the crash.
LMMS tries to load DLLs in the working directory. It seems like LMMS crashes while loading AppVTerminator.dll(~The DLL contains a string IllBeBack, really. :rofl:~).
After some testing, I found that the LadspaManager constructor loads that DLL.
https://github.com/LMMS/lmms/blob/1c1575cc86b24e8fbbf2b5a4894863a8203647b9/src/core/LadspaManager.cpp#L45-L47
ladspaDirectories may contain empty entries, and it's treated as the working directory when constructing QDir. This adds undesired search paths(C:\Windows\System32 in this case) and makes LMMS crash.

[PhysSong]

The fix is very simple, excluding empty search paths. I think this may be added to stable-1.2 if we're going to release more bug-fix releases.

[tresf]

@PhysSong this is a fantastic finding! In regards to it landing on stable-1.2, I'd argue against it. It's over 4 years old with very small impact.