Lock-ups in extensions spawning an inkscape process via Popen

[San Siro]

Hello,

I have windows 10 on my pc(Lenovo Z500). Installed yet Inkscape 0.92 and saw some issues on it. Can not use most of Extensions especially under the Modify Path (envelope, perspective etc.) ones. Whenever process them Inkscape stuck on extension window.

After that stuck I had to close Inkscape over Task Manager. However terminate the process of Inkscape it still works background. And uses too much CPU. So I had to terminate Inkscape again again until process closed totally.

[Patrick Storz (ede123)]

I'm afraid this might be a python / python-related issue:
From the looks of it Python tries to compile some files to bytecode (*.pyc) but can't save them due to access problems.

In my own tests I could reproduce the issue when running Inkscape 0.92.0 x64 installed via the exe installer. When running Inkscape from a directory without limited write access the issue does not occur as does running Inkscape with administrative rights (in both cases *.pyc files are created). After running Inkscape with administrative rights once it works without elevation, too.

@San Siro: Do your run Inkscape from "C:\Program Files" (or another location with limited file access?)

[San Siro (sansirofult)]

Eduard Braun thanks for your respond,

In normally I always launch programs from windows start menu or desktop shortcut. After your advice I had tried for opening Inkscape's .exe from its folder with administrative rights. Result is nearly same like previous issue. Only perspective extension worked tough envelope got stuck.

What should I do personally, use 32-bit version or .msi installer until finding solution for that bug?

Thanks again

[Patrick Storz (ede123)]

@San Siro: Both, envelope and perspective extensions, work fine for me in both 64-bit and 32-bit builds when launched once as administrator (I'd recommend that as the current workaround).

As for .exe vs .msi installer: Shouldn't make a difference as long as you install into "C:\Program Files". You could install into a location where no administrative rights are needed for file write access.

[San Siro (sansirofult)]

Oww sorry I misunderstood that launching .exe from folder with administrative rights where no matter files stored. I see you brief that I should install my Inkscape folder rather than under "\Program Files" because of limited write access.

After your proposal I have installed Inkscape on "C:\Portable Apps\Inkscape" folder where no require any admn. rights to write access. However Extensions not worked properly again :(

Then I tried some other primitive ways like killing process after extension launch window. Yeah... Whenever extension launched then CPU usage goes pick and machine gets stuck. So I preferred to kill the process on task manager after extension dialog window appear. And stuck windows dropped and extensions WORKED...

It's abnormal solution and not a proper way but I have to use it until bug fixed. Thanks for all your handy help.

*Addition the new situation:

-Should I reinstall my Inkscape on Program Files? Any settings will affected with this change? Thanks.

[Brenda Collins (gentlebath)]

I just updated my Inkscape from v.48 to v.92 and have had a ton of bugs and issues along with this a high cpu use after I exited the program.

Mine is installed on >programs86x>Inkscape which is the same path my old one was installed. I renamed my old Inkscape folder Inkscape48 and then installed .92 as a fresh install.

Is there a way to roll back to .91 whilest all the bugs are being worked out? There is just too many to get my work done in an efficient manner.

The worst is the constant loss of the selection tool. It seems to stop all the time and I have to click on another tool and then click back to select to get it going again. And I thought I was missing something.

Windows7/pc

[Mc (mc...)]

Hi,

maybe not the best place to discuss it here, but you can check if the situation is better with 0.92.1pre1<https://inkscape.org/gallery/item/10647/Inkscape-0.92.1pre1-win64_AShOEGj.7z>.

If not, here is the 0.91 download link: https://inkscape.org/en/release/0.91/platforms/

[Alvin Penner (apenner)]

>> Both, envelope and perspective extensions, work fine for me in both 64-bit and 32-bit builds >> when launched once as administrator (I'd recommend that as the current workaround).

thanks very much for the tip! I have Inkscape 0.92.0 r15299 installed in the
C:\Program Files (x86)\Inkscape\ directory on Windows 10, and I was wondering why it occasionally hung up. I had not one .pyc file in the extensions folder, and now, after running it as an administrator and running some extensions, I have 9 .pyc files. I assume that it is not not necessary to constantly run it as a administrator, unless I want to compile a new pyc file that has never been used before?

anyways, much appreciated, I vaguely recall wondering where they were, but I thought perhaps Windows had magically relocated them somewhere else (wouldn't be the first time that happened).

[Alvin Penner (apenner)]

but I have to ask, is this behavior new? I am running the 32 bit exe version of 0.92.0. I don't recall experiencing this before.

[Patrick Storz (ede123)]

Well, I assume it is not new, I guess it just wasn't visible before as we simpy shipped and installed pre-compiled .pyc files.

I'm afraid I was too accurate when lately updating devlibs64, but also CMake and the installer scripts: In all these steps I started to exclude files unnecessary for the final distribution - also .pyc files.

Now I'm still of the opinion that we should *not* ship .pyc files as those are cache files of the compiled Python bytecode (i.e. they are generated from the corresponding .py file). They can be easily generated after installation and in fact they are (at least inprinciple) system dependent. As we ship Python with our Windows distributions we can assume that most people will probably use the same version of Python, but if this was not the case or if a user decided to update an extensions the bytecode file would have to be re-created.

I had previously hoped that those files would simply be put into Windows's "Virtual Store" folder, but it seems that is somehow not the case and Python fails instead (I have not yet determined which step actually fails as some extensions work fine while others obviously won't).

Right now I see three possible solutions:
* Drop the idea of stripping .pyc files from the installer packages and hope for the best (i.e. that most people will never try to update extensions)
* Tell Python not to create/use .pyc files at all. There are even three different possibilities for this: The "PYTHONDONTWRITEBYTECODE" environment variable, the "-B" command line switch and also "sys.dont_write_bytecode=True" directly from python scripts.
* Try to figure out the actual issue, and fix it (or get it fixed by Python devs, depending on where the issue is).

While the third options is obviously the hardest it would also be the cleanest and (for me) preferred option.

[Alvin Penner (apenner)]

>> I had previously hoped that those files would simply be put into Windows's "Virtual Store" folder,

yes, I had thought that this would happen automatically as well. I mean, it has happened more than once that I would accidentally save a file into a system folder and then discover that it had automatically been re-directed, so I am not sure why these .pyc are not being automatically re-directed.

[Patrick Storz (ede123)]

Hmm... this issue is really strange (read: might not even be related to .pyc files in the way I thought). For example Scour always works fine for me and it certainly uses modules.

Some things I noticed:
- One similarity between the two conflicting extensions is that they both try to spawn a new instance of Inkscape via "Popen", though.
- I tried to execute the command in question and at least when executed manually on the command line it doesn't fail.
- However it's obvious that at some point the spawned subprocess is locking up: If you look in task manager you'll find your original inkscape.exe (0% CPU) the spawned inkscape.com (0% CPU) and it's own inkscape.exe (100% of one core).

Question is: What is the spawned instance of Inkscape doing, and why is it locking up?

[Patrick Storz (ede123)]

PS: Killing the spawned instance let's one at least continue to use Inkscape...

[Patrick Storz (ede123)]

And it gets stranger:
I evaluated the exact command the envelope extension is using in Python on the commandline:

p = Popen('inkscape --query-x --query-id=rect10 "C:\Users\Eduard\AppData\Local\Temp\ink_ext_XXXXXX.svg06TNVY"', shell=True, stdout=PIPE, stderr=PIPE)
rc = p.wait()
res = float(p.stdout.read())
err = p.stderr.read()

And guess what: When exectuing all commands at once "res" is undefined. When executing them one after the other "res" contains the proper value. In both cases no deadlock, though.

Now I'm really starting to suspect that this is some kind of really ugly timing issue with the Popen command (maybe that's why it doesn't occur when bytecode of the "subprocess" module is available?). When you look at [1] there are a *lot* of warnings about using Popen in the way this extension does...

[1] https://docs.python.org/2/library/subprocess.html#popen-objects

[Alvin Penner (apenner)]

>> using Popen in the way this extension does...

yes, there is an alternative usage proposed at:
https://github.com/Moini/inkscape-extensions-multi-bool/blob/master/multiplecut.py

[Alvin Penner (apenner)]

@Eduard - <offtopic>
I wonder if you would be in a position to test either https://bugs.launchpad.net/inkscape/+bug/1663697
or
https://bugs.launchpad.net/inkscape/+bug/1662531
using a recent Windows trunk build?
In both cases I am getting a crash that happens only on Windows and so far only for me. These two bugs are kind of interesting because they both involve the use of Popen with Inkscape verbs
</offtopic>

[Brenda Collins (gentlebath)]

@MC THANKS _ I better go back to .91, since I was on .48, it still should be a big leap for me.

I had 25% CPU usage after quitting V .92 again tonight. My task manager also showed inkscape as "running" even though it was closed. I had to go and end the process to stop the usage and get the CPU back to normal. I attached a screenshot of my resource monitor in case that helps.

Reading through this bug I don't use extensions, at least I don't think so if that mean extensions in IS. I was only in a basic svg file with a few layers and not even using any filters.

Not sure if this is the same bug but it seems to be the same high CPU usage after quitting. I could hear the fan rev up and checked my task manager and it listed Inkscape at the top even though I had closed it.

Windows 7 PC
V .92

[Patrick Storz (ede123)]

@Brenda: Your issue is probably unrelated to this report.

However we had a similar report in bug #1659172 (independent of extensions). Can you reproduce the issue with Inkscape not closing properly consistently?

This could obviously have many ugly side-effects and I'd really like to figure out what's causing it...

[su_v (suv-lp)]

On Windows 10:
- not reproduced with Inkscape 0.91 32bit, 64bit
- not reproduced with Inkscape 0.92.0, 0.92.1, 32bit
- reproduced with Inkscape 0.92.0, 0.92.1 64bit

All tests done with 7z packages installed into custom location (sub-folder of 'C:\Users\%USERNAME%\Programs\inkscape'), launching inkscape from the terminal (Command Prompt).
No MSI or exe version installed into default location. Previous default installation of Inkscape (64bit, MSI) had been uninstalled earlier.

[Patrick Storz (ede123)]

I've not seen this issue re-appear in Inkscape 0.92.2 release so far, so I think it's safe to assume it was fixed.

If anybody still experiences this with Inkscape 0.92.2 please report back, so we can look into it again.