command line sometimes freezes

Thanks for taking the time to file a report!

Does it happen with some specific SVG files? If so, could you please attach a copy so that we can investigate?

Because it happens with the version command alone, ("C:\Program Files\Inkscape\inkscape" -V), which doesn't convert anything, I think it doesn't have to do with any specific SVG files. Just now, (always good to double check), I put in that command into the command line and the 5th try made it freeze without returning control to the command line (cpu at 15-18%).

> Because it happens with the version command alone

Oh, sorry, I completely missed that part!

Just tested on Windows XP (32-bit) with lp:inkscape/0.92.x rev. 15346, and not reproduced here. I launched the "inkscape.com -V" command about 120 times from the command line interface, and I saw no running Inkscape instance in the task manager.

To be confirmed on a 64-bit Windows computer.

Just tried the following on Windows 10 x64 using Inkscape 0.92.0 r15299 (64 bit):

FOR /L %%G IN (1,1,100) DO "C:\Program Files\Inkscape\inkscape" -V

However not even one Instance of Inkscape remained in memory.
I also tried varying the command to "inkscape.com" and "inkscape.exe", and even changed it to export an .svg to .pdf or .png without change, so there seems to be more to this issue.

On the off-chance that this is yet another incarnation of bug #1528629:
Did you try to wait some minutes for the command to succeed?

That being said I sporadically noticed inkscape.exe continuing to run in background using up one CPU core after closing the GUI. However I was never able to reproduce it in a controlled environment and usually did strange things before (i.e. using multiple instances / versions of Inkscape side-by-side, debugging stuff, etc. so it could be unrelated.

As to the possible questions about different versions, I did the following: (Summary: only the 64bit 0.92 version would ever freeze, not 32 bit 0.92 and not 64bit 0.91)

1) Trying "FOR /L %G IN (1,1,100) DO "C:\Program Files\Inkscape\inkscape" -V": I had to end inkscape manually 51 times.
2) I un-installed and re-installed 0.92 x64 from exe. Running the loop again for only 10 times required manually closing inkscape 5 times.
3) I uninstalled 0.92 and re-installed 0.91: the 100x for loop didn't freeze on close even once. It returned: Inkscape 0.91 r13725 (Jan 30 2015)
4) I uninstalled 0.91 and re-installed 0.92, but from msi this time. "C:\Program Files\Inkscape\inkscape" -V" froze first time by itself. But it returned "Inkscape 0.92.0 r15299" first, before freezing: It always completes the appropriate action before freezing. I left it running for more than 7 minutes before killing it.
5) I uninstalled 0.92 x64 and installed 0.92 x32 (Inkscape-0.92.0-1.exe). "C:\Program Files (x86)\Inkscape\inkscape" -V returned Inkscape 0.92.0 r15299.
[FOR /L %G IN (1,1,10) DO "C:\Program Files (x86)\Inkscape\inkscape" -V] all worked
So did [FOR /L %G IN (1,1,100) DO "C:\Program Files (x86)\Inkscape\inkscape" -V].
6) Uninstall 32bit inkscape 0.92, re-install 64bit inkscape 0.92 (Inkscape-0.92.0-x64-1.exe): ["C:\Program Files\Inkscape\inkscape" -V] froze first time on close (it returned "Inkscape 0.92.0 r15299" before freezing). I left it for 2 minutes before closing it. [FOR /L %G IN (1,1,100) DO "C:\Program Files\Inkscape\inkscape" -V] needed to be closed only 3 times this time around.

Could you try if it also happens when using the 7z archive (i.e. not installing to "C:\Program Files")? I want to rule out that it's some type of file access issue...

Also (it it's not too much to ask of you): Could you check the inkscape.exe process with the tool "Process Explorer" [1] when it's in a locked-up state?
You can get *a lot* of informations on the properties of the running process, including information of CPU usage of single threads of the process in question (so maybe we can figure out which thread and therefore which part of the code is responsible...)

[1] https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

The 7z archive also froze. I already had Process Explorer on my computer, so I took screenshots with the 7z version running and the prior 64bit version installed from exe. I'm not sure exactly what you're looking for, or if there is a better way to get you the information. Let me know, I'm glad to help explore any details as needed.

Marshall: In the context menu of each process there's a "Properties" entry. Especially the "Threads" and "Environment" tabs are of interest.

The actual child process thread that is eating cpu will close every time I open properties to the threads tab, so I'm getting nothing from it. But I can see that there are 10 associated threads in the handles view before attempting to open the properties. I've attached a screenshot of the "Environment" tab (same for parent and child process shown in Process Explorer tree view).

From the "parent" inkscape thread properties (obviously the thread # changes every time, but the stacks are the same):

Stack for thread 15860: (inkscape.com+0x1500) [State: Wait:UserRequest]
ntdll.dll!NtWaitForSingleObject+0x14
KERNELBASE.dll!WaitForSingleObjectEx+0x8f
inkscape.com+0x30c3
inkscape.com+0x13e8
inkscape.com+0x151b
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

Stack for thread 20748: (inkscape.com+0x15b0) [State: Wait:Executive]
Stack for thread 17180: (inkscape.com+0x15b0) [State: Wait:Executive]
Stack for thread 14988: (inkscape.com+0x15b0) [State: Wait:Executive]
 (all three have same stack)
ntdll.dll!ZwReadFile+0x14
KERNELBASE.dll!ReadFile+0x74
inkscape.com+0x1608
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

Stack for thread 20116: (ntdll.dll!RtlReleaseSRWLockExclusive+0x1370) [State: Wait:WrQueue]
  (This one sometimes goes away while inkscape continues to run)
ntdll.dll!NtWaitForWorkViaWorkerFactory+0x14
ntdll.dll!RtlReleaseSRWLockExclusive+0x1ade
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

I took a trace of events using Process Monitor as well. I end recording the trace while inkscape is still running in the background.
I noticed that closing the "inkscape.com" process (via kill or ctrl-c at the command line) won't close the "inkscape.exe" process that is consuming cpu. Killing "inkscape.exe" will close the "inkscape.com" process.
You can open the file in Process Monitor and see stacks associated with each thread create, exit, file access events, etc. You can probably extract from it which threads of inkscape.exe weren't closed and the associated stacks (which I couldn't get from Process Explorer because inkscape would close when I tried to get to the properties thread tab).

> The actual child process thread that is eating cpu will close every time I open properties to the threads tab

Interesting, same thing happened for me while debugging bug #1655619. Maybe they're related after all?

One other question: Have you ever seen Inkscape freeze (i.e. not shut down properly) when *not* running from the command line?
Also: Is there a difference between calling inkscape.com and inkscape.exe directly?

I'll look at the log later.

Inkscape.com vs inkscape.exe: I didn't know this before, but apparently ".com" is a type of executable (a DOS executable), just like a ".exe" is an executable. Before when I noticed the process I was just assuming it was the name of the thread/process, like a website, kind of like how website names are frequently used for namespaces in java.

When I call "C:\Program Files\Inkscape\inkscape" from the command line, it opens only the inkscape.exe as a GUI (returning "FontLister::get_best_style_match(): can't find family: Sans" at the command line).

With the command line argument (adding -V at the end) it executes inkscape.com, which apparently then executes inkscape.exe. If I run ["C:\Program Files\Inkscape\inkscape.exe" -V] at the command line (i.e. explicitly calling the .exe), then it still sometimes freezes, but never returns the version, whether or not it stays open in the background.

I haven't used the GUI for this version of inkscape much yet, and haven't explicitly noticed it running in the background after closing it. So now, I tried opening and closing the GUI and eventually it does stay open running at high cpu in the background even though it "closed".

I am not sure what the correct terminology is, but if you run inkscape.exe, it will run independently of DOS. You will regain control of DOS immediately and Inkscape output will not be sent to DOS. If you run inkscape or inkscape.com, then the output will be sent to your DOS window, and you will regain control of DOS only after Inkscape terminates.

Explanation of inkscape.com vs. inkscape.exe:
On Windows you can have either console applications or GUI applications. Console applications don't have a window but can easily output text to the console. GUI applications do have a window but can not easily write output to the console.

To work around this issue we build two executables:
- inkscape.exe is the actual Inkscape application and is compiled as a GUI application (using GCCs "-mwindows" linker flag).
- inkscape.com is a wrapper that is compiled as a console application (using GCCs "-mconsole" linker flag). It only sets up console input/output and links it to a newly spawned instance of inkscape.exe.

In other words: If you run inkscape.com you'll always end up with a child process of inkscape.exe. Running inkscape.exe directly will only create one process.

When running "inkscape" (without extension) Windows will pick the first executable matching this file name when omitting the file extension and therefore will always launch inkscape.com (as it's first alphabetically).

> it opens only the inkscape.exe as a GUI (returning "FontLister::get_best_style_match(): can't find family: Sans" at the command line).

Simply set the font to "sans-serif" in the text tool and the error will be gone ("Sans" was a non-standard alias for the default sans serif font in Inkscape < 0.92).

> I tried opening and closing the GUI and eventually it does stay open running at high cpu in the background even though it "closed".

That confirms my fear that the issue is in inkscape.exe itself (and not an issue in the wrapper). On the other hand it narrows down our search as we don't have to bother with inkscape.com anymore.

Regarding the issue: I'm at a loss. I looked at the Process Monitor log but (at least I) am not able to get any useful information from it.
The fact that the issue occurs sometimes but not always makes me assume it's a timing issue or some really ugly issue with code executing in random order which I have no idea how to debug...

Since the platform hasn't been mentioned yet. Affecting me as well on Windows 7 x64.

Calling the 64-bit inkscape.exe from the command line directly has a chance to never finish. 32-bit version is not affected.

I'm having this problem on Windows 10 x64. I've created a batch script to export a series of .svg files to .pdf. At certain points, the .pdf files are generated correctly but the Inkscape process stays there, consuming 10% of CPU everytime. As the process didn't finish, the batch script can't continue.

Edit: As the process didn't finish, the batch script can't continue and I have to finish it manually everytime.

I did some testing with running "inkscape -V" 100 times (using version 0.92.1).
I tested all combinations of the following:

- distribution type
  - x86 exe installer
  - x64 exe installer
  - x86 7zip
  - x64 7zip

- execution type (see uploaded files, all these files were placed in %appdata%\inkscape\extensions)
  - running the bat file from command line in the inkscape install directory
  - starting the python extention out of the inkscape extention menu
  - running the python extention from command line ("python\python <path\to\script.py>" in the inkscape install directory)

- privilegies
  - normal
  - run as administrator (start cmd.exe or inkscape.exe with right click, run as administrator)

The expected behaviour for inkscape is to exit with exit status 0 after a short time. In the following cases, an other behavior was observed:

x64 installed, without admin privilegies, extention on command line: inkscape exits with exit status -1073741819 (ca. 99 out of 100 started processes), but NOT when no inkscape process was started from THIS cmd window before

x64 installed, without admin privilegies, extention in gui: inkscape freezes (ca. 1 out of 5 started processes)

x64 7zip, WITH admin privilegies, bat: inkscape freezes (ca. 1 out of 2 started processes)

x64 7zip, WITH admin privilegies, extention on command line: inkscape freezes (ca. 1 out of 2 started processes), but NOT when no inkscape process was started from THIS cmd window before

Edit: Tests were done on Windows 8.1 Pro 64bit

@Nokir: Thank you for these very extensive tests!

If I interpret your results correctly this means all configurations crash occasionally? The thing with frequency is that I already observed that this is *extremely* arbitrary (sometimes it does not happen at all, at other times it happens almost all the time). So it might well be that if you try the same tests tomorrow the results might look differently.

What you might try: There are development builds using MSYS2 available from [1]. They still lock up occasionally I'm afraid, but maybe that has other reasons. (At the very least it's worth a try...)

Also I did some experiments the last two days with a newer version of "libgc" (the library we use for garbage collection). In the new versions a lockup issue was worked around (I'm not sure if we were affected but who knows...). You can get a brand new nightly build including that updated version directly from [2] (select a build, MING32 for 32-bit / MINGW64 for 64-bit and click on artifacts to get to the download link).

[1] https://download.tuxfamily.org/inkscape/
[2] https://ci.appveyor.com/project/inkscape/inkscape

Out of the 24 combinations I tested, 3 combinations froze and one combination had the wrong exit status. All 20 other combinations were fine. For example, I had not a single frozen 32bit process.

Ah, sorry, I misread...
So basically 64-bit versions have shown to be problematic, which is probable as they're based on a completely different build system (mingw vs mingw-w64, where the -w64 does not simply mean "64-bit" but is a significantly diverged fork of the former).

I'm not sure if the further differentiation into execution type / privileges really can be trusted as there seem to be additional factors involved, e.g. you noted different behavior depending on wether you launched Inkscape on a command line before or not. I'm not sure if this really can affect the Inkscape process directly (it should not as far as I know) unless we change environment (which I'm pretty certain we do not; it can be quickly checked by executing the "set" command to print all environment variables before and after running Inkscape and on my system the output is identical). So I'm really suspecting something very fundamental...

If you (or somebody else who's frequently experiencing hangs) could test the newer MSYS2 builds that could be helpful. They're also based on mingw-w64 (this time both 64-bit but also 32-bit builds) but use significantly newer library versions and some additional patches/fixes which were not included in the mingw-w64 build currently used for stable releases.

P.S. Sorry if I sound a bit skeptical towards your undoubtedly very systematic tests, but from everything I learned so far the issue is highly un-systematic, so it's hard to trust tests one does today as results might differ tomorrow. I did not only think once that I finally found the source (no more hangs!) only to experience the same issues again with seemingly identical parameters some time later... (For all I know it might be an uninitialized variable / invalid pointer and behavior may change on every run depending on the memory layout).

I tested these:
https://download.tuxfamily.org/inkscape/win32/inkscape-0.92.x-15414-win32_MSYS2.7z
https://download.tuxfamily.org/inkscape/win64/inkscape_0.92.x_r15429_win64_MSYS2.7z
https://ci.appveyor.com/api/buildjobs/v1k37029lj2h1hmy/artifacts/build%2Finkscape-0.92%2Bdevel_2017-08-09_305337d-x86.7z
https://ci.appveyor.com/api/buildjobs/sq0rn4gy5u925nqi/artifacts/build%2Finkscape-0.92%2Bdevel_2017-08-09_305337d-x64.7z

I was not able to reproduce the freezes with these builds.

To be sure, I tested https://inkscape.org/gallery/item/10687/Inkscape-0.92.1-x64.7z again, the freezes still happen.

That's great news!

FYI we just released Inkscape 0.92.2 which is built the same way as those you cited, so I'm optimisitc we could overcome this.

I'm not completely sure what might have fixed it, though. Likely seem:
- the fix for bug #1670688
- the switch of Python (new builds use a custom gcc-built Python instead of the "official" Python built with Visual C++
- an update to libgc (the library we use for garbage collection) which fixed at least one dead-lock scenario.

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.

Hi All,
Firstly - many thanks for providing this support forum. I was facing a problem very similar to what is being discussed here. My platform is Windows Server 2016.

I was using the version "0.92.0 r15299" and the executable would hang randomly.

When I switched to "0.92.3 (2405546, 2018-03-11)" , the problem disappeared.

Just thought I should let you all know.

Thanks,
Saurabh