Command line output partially broken in 0.92.2

Bug #1714278 reported by Eduard Braun on 2017-08-31
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Eduard Braun

Bug Description

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.

Changed in inkscape:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Eduard Braun (eduard-braun2)
Eduard Braun (eduard-braun2) wrote :

As I suspected this is not always happening.

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

Eduard Braun (eduard-braun2) wrote :

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)

Eduard Braun (eduard-braun2) wrote :

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

Eduard Braun (eduard-braun2) wrote :

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?

Eduard Braun (eduard-braun2) wrote :

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

Eduard Braun (eduard-braun2) wrote :

gdb backtrace of the crash on Windows 7

Eduard Braun (eduard-braun2) wrote :

Unfortunately it seems to crash on Windows 10, too

Eduard Braun (eduard-braun2) wrote :

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

Eduard Braun (eduard-braun2) wrote :

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.

Eduard Braun (eduard-braun2) wrote :

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.

Eduard Braun (eduard-braun2) wrote :

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)

Eduard Braun (eduard-braun2) wrote :

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

Eduard Braun (eduard-braun2) wrote :

A fix for Aspell was found!

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

Changed in inkscape:
status: Confirmed → In Progress
Eduard Braun (eduard-braun2) wrote :

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?

Changed in inkscape:
status: In Progress → Fix Committed
milestone: none → 0.92.3
Ron Burk (ronburk) wrote :

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.

Bryce Harrington (bryce) on 2018-05-12
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers