Skip to content
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

Opening mmpz from within zip file crashes LMMS #2569

Closed
repsej opened this issue Feb 15, 2016 · 16 comments · Fixed by #5677
Closed

Opening mmpz from within zip file crashes LMMS #2569

repsej opened this issue Feb 15, 2016 · 16 comments · Fixed by #5677

Comments

@repsej
Copy link

repsej commented Feb 15, 2016

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).

image

@repsej
Copy link
Author

repsej commented Feb 15, 2016

Sorry for the danish text ... it reads:

"Microsoft Management Console has stopped working"

etc. etc.

@DeRobyJ
Copy link
Contributor

DeRobyJ commented Feb 15, 2016

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
Copy link
Member

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
Copy link
Member

tresf commented Feb 16, 2016

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
Copy link
Member

tresf commented Feb 16, 2016

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
Copy link
Member

tresf commented Feb 16, 2016

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
Copy link
Author

repsej commented Feb 16, 2016

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

@musikBear
Copy link

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

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

@softrabbit
Copy link
Member

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
Copy link
Member

tresf commented Feb 16, 2016

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
Copy link
Member

tresf commented Feb 16, 2016

@musikBear

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

Stop using XP.

@musikBear
Copy link

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
Copy link
Member

tresf commented Feb 17, 2016

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

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

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

@tresf tresf changed the title crash on when trying to load a project from a zip file (windows 10 64 bits) Opening mmpz from within zip file crashes LMMS Feb 17, 2016
@PhysSong PhysSong added the bug label Oct 7, 2017
@PhysSong
Copy link
Member

PhysSong commented Aug 17, 2020

@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. 🤣).
After some testing, I found that the LadspaManager constructor loads that DLL.

QStringList ladspaDirectories = QString( getenv( "LADSPA_PATH" ) ).
split( LADSPA_PATH_SEPERATOR );
ladspaDirectories += ConfigManager::inst()->ladspaDir().split( ',' );

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 PhysSong added this to the 1.3 milestone Aug 17, 2020
@PhysSong PhysSong self-assigned this Aug 17, 2020
@PhysSong PhysSong removed this from the 1.3 milestone Aug 17, 2020
@PhysSong
Copy link
Member

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
Copy link
Member

tresf commented Aug 17, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants