Command line output partially broken in 0.92.2

[Patrick Storz]

I just noticed Inkscape does not always properly produce output on the command line.

While "inkscape --help" works, "inkscape --version" does not.

This might be an issue exclusive to MSYS2 builds:
- Inkscape 0.92.1 r15371 produces output
- Inkscape 0.92.2 (5c3e80d, 2017-08-06) does *not* work

OS is Windows 7 x64.

[Patrick Storz (ede123)]

As I suspected this is not always happening.

I could not reproduce this issue on
- Windows 10 x64
- Windows XP x86

[Patrick Storz (ede123)]

Now also reproduced on Windows 7 x86.

If I didn't overlook anything this does in fact seem to be a Win7 issue!
(Didn't check Vista / Windows 8 - tests welcome)

[Patrick Storz (ede123)]

From some preliminary tests this seems to be a flushing issue:
- Even the simple "printf("Inkscape %s\n", Inkscape::version_string)"
  in "sp_process_args()" does not output anything
  (it should output the version string)
- Forcing flushing of stdout via "fflush(stdout);"
  makes the output appear even won Windows 7
- Similarly using stream output via "std::cout" produces
  output on the command line
  (probably it's doing some flushing internally)

However I did not find the source of the issue yet:
- A simple sample program outputs flawlessly
- I even ran that sample program through the .com command line
  wrapper we need to redirect output of inkscape.exe to the command
  line and it still works

So Inkscape still seems to be doing something which messes up the output somehow...

[Patrick Storz (ede123)]

This might actually be caused by the Inkscape process not properly shutting down.

While it's not an obvious crash, it obviously could cause unflushed buffers (and therefore missing messages) on exit.

Questions are:
- Why is this happening?
- How could it be debugged?

[Patrick Storz (ede123)]

I just confirmed that this seems to be caused by an improper shutdown.

When executing
- "start /wait inkscape.exe -V"
- "echo %errorlevel%"
the version number an a zero exit level should be returned (which is the case e.g. on Windows 10).
On Windows 7 I'm getting no version number output and an error level of "-1073741819".

[Patrick Storz (ede123)]

gdb backtrace of the crash on Windows 7

[Patrick Storz (ede123)]

Unfortunately it seems to crash on Windows 10, too

[Patrick Storz (ede123)]

As already apparent from the backtraces above the issue seems ugly and happens on exit.

Even worse: If I empty out main.cpp and replace it with a dummy main() function this function still crashes so the issue seems to be in whatever we link against... (not the actual code we execute in main()).

[Patrick Storz (ede123)]

Turns out the crashes on exit are not even new...
Just confirmed Inkscape 0.92.1 (devlibs64 build) crashed, too, under these circumstances.

I'm not sure this is really what's causing the missing output but it's certainly bad.

[Patrick Storz (ede123)]

Going even further back this seems to be a mingw-w64 issue.

All devlibs builds since Inkscape 0.91 (devlibs builds used TDM GCC which is based on the original MinGW) seem to be unaffected.

devlibs64 builds and MSYS2 builds (both based on mingw-w64) seem to crash on exit.

I'll now look into building without Aspell (as it's often showing up in the backtraces).
Another likely candidate (which might be related - at the very least it once broke compilation of Aspell) is the updated winpthreads used in mingw-w64.

[Patrick Storz (ede123)]

Yes! Aspell is the culprit!

Just compiled 0.92.x as well as trunk without Aspell and both builds properly output to the Windows 7 console and don't crash anymore upon exit.

So, next up: can we fix Aspell?
(using Aspell through Enchant causes the same issue as still apparent by the gtkspell implementation in the "Text and Font" dialog, so making bug #1049548 happen won't be enough, we'd still need to change the backend)

[Patrick Storz (ede123)]

Issue was discovered before (minus the command line output issue), see bug #1412365.

[Patrick Storz (ede123)]

A fix for Aspell was found!

The merge request is pending for MSYS2:
https://github.com/Alexpux/MINGW-packages/pull/2872

[Patrick Storz (ede123)]

Now merged upstream.

I'm not sure if it warrants a new revision (as was suggested in bug #1715339)? Thoughts?
Maybe we can just refer people to "debug builds" for debugging?

Then again crashes on exit might cause all sorts of undefined behavior (e.g. there was a report on IRC that Inkscape reset preferences on each start - unfortunately the reporter went away - but maybe they weren't properly saved due to the crash?), so maybe better to fix it in a new release then to find out all the dirty details in separate bug reports?

[Ron Burk (ronburk)]

FWIW, the "all sorts of undefined behavior" that bit me was simply the exit code (pretty reliably 0xC0000005 on my Windows 7 64-bit box). I was trying to automate the "build" of a book that contains many figures created in Inkscape. The result was my little build program would keep claiming that system("inkscape foo.svg ...") was failing, even though it looked like it created the correct output .png file. After hours of tinkering, I finally found this bug thread. Off to try 0.92.3 to see if that brings joy. Obviously, I really do want to know when inkscape fails to create the png, rather than just ignore the error code.

Might be worth mentioning the bogus exit code on the bug label.