failure to load most emf files, rev 14600

[Alvin Penner]

- running Windows XP, Inkscape rev 14600
- I have tried to load about 15, or so, emf file into rev 14600 on Windows XP.
- about three quarters of these files failed to load, with a few successes, and one partial success.

- not reproduced on Windows 7 (32 bit), Inkscape 0.91 r13725 (Jan 30 2015)

- attached is a failure:

[Alvin Penner (apenner)]

attached is a success:

[Alvin Penner (apenner)]

attached is a partial success, text is missing:

[su_v (suv-lp)]

On OS X 10.7.5, loading the files (with default (new) prefs) from the command line:
1) example1.emf:
opens ok in Inkscape 0.91, fails to load in Inkscape 0.91+devel r14615
2) Figure10.emf:
opens ok in Inkscape 0.91 and 0.91+devel r14615 (render the same)
3) phase_dome_isobutane.emf:
opens ok in Inkscape 0.91 and 0.91+devel r14615 (render the same)

Based on tests with archived builds:
- example1.emf opens ok with rev <= 14061,
- example1.emf fails to load with rev >= 14063;
(one of ) the regression(s) seems to be related to the changes in rev 14062 for bug #1447850 and bug #1447382.

* Relevant changelog:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/14063

* Related commits:
Revision 14062: patch for bugs 1447850 and 1447382
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14062
Revision 14063: add two files omitted in patch at revision 14062
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14063

[David Mathog (mathog)]

I just loaded example1.emf and phase_dome_isobutane.emf into revision 14616 and they both look OK. Well, the latter one does anyway, it has text in all the places I would expect to see it in a diagram like that.

The first one has text of "nec accumsan velit malesuada" in the top half of each rounded rectangle, which means nothing to me, and the bottoms are all empty. It looks just like that in XP Preview too though. Could you post the SVG if this isn't the expected result?

Or update to revision 14616 and see if that fixes the problem.

[David Mathog (mathog)]

I should add, this was only tested in linux. I don't have time now to wrestle with the new devlib for a new windows build.

[David Mathog (mathog)]

How did you load the ones that failed? From the GUI or from the command line? Any other options if it was on the command line?

The tests above were from the GUI, and these worked for me also:

src/inkscape /tmp/phase_dome_isobutane.emf
src/inkscape /tmp/example1.emf

This was on Ubuntu 14.04 LTS, 32 bit.

[Alvin Penner (apenner)]

I loaded them all using the gui, with File->Load

[Alvin Penner (apenner)]

attached is the backtrace I get when trying to load the file ex1.emf, attached here

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) symbol-file inkscape.dbg
Reading symbols from C:\InkscapeBZR\inkscape/inkscape.dbg...done.
(gdb) run
Starting program: C:\InkscapeBZR\inkscape/inkscape.exe

Program received signal SIGSEGV, Segmentation fault.
0x34363530 in ?? ()
(gdb) bt
#0 0x34363530 in ?? ()
#1 0x09566fc8 in ?? ()
#2 0x39373237 in ?? ()

...

#937 0x302c3030 in ?? ()
#938 0x3030302e in ?? ()
#939 0x29303030 in ?? ()
#940 0x00000a22 in ?? ()
#941 0x00090009 in ?? ()
#942 0x01485fe8 in vtable for SPIEnum ()
#943 0x094c2a3c in ?? ()
#944 0x00000001 in ?? ()
#945 0x01341ea0 in enum_font_variant_ligatures ()

[Alvin Penner (apenner)]

I just re-tested my set of emf files using devlibs rev 58 and Inkscape rev 14617, using Windows XP.
These files were all loaded using a right mouse button click in Windows Explorer, and then selecting "Open with Inkscape".
All these files open successfully in Windows 7 (32 bit), Inkscape 0.91 r13725 (Jan 30 2015)

In trunk the files fall into four categories.
First category is an Inkscape crash with the message :
"Inkscape encountered an internal error and will close now"
This is 10 files in the attached zip file

[Alvin Penner (apenner)]

Second category is an Inkscape failure to load with the message :
"Failed to load the requested file"
 This is 1 file attached here

[Alvin Penner (apenner)]

Third category is a partial success, with text missing :

  This is 3 files in the attached zip file

[Alvin Penner (apenner)]

Fourth category is a complete success, with no text in the file :

  This is 1 file attached here.
This file appears to contain text, but it is in the form of a path outline, not actual text.

[su_v (suv-lp)]

Testing the second set of test cases provided by Alvin on OS X 10.7.5 with 0.91+devel r14617, I can only reproduce the failure to load of 'EMF_Illustrator_a4.emf' (from the command line as well as from within Inkscape). All other files open ok (no crashes, all text visible, content renders the same as with Inkscape 0.91r13725).

Since most of the regressions (crashes, omitted text) appear to be a Windows issue (or possibly a 32bit devlibs issue related to older versions of dependencies like pango), I'm bowing out from further tests for now.

[David Mathog (mathog)]

Re comment 9 - that binary needs to be rebuilt with -g -O0, otherwise the crash information isn't useful.

On my 32 bit linux r14616 test system I just opened all of the InternalCrashError.zip files with no problems

EMF_illustrator_A4.emf did not open. When run in reademf the dump ends with:

U_EMR_SELECTOBJECT record: 9 type:37 offset: 240 rsize: 12 crc32:145418AD
   ihObject: 1
ABORTING on invalid record - corrupt file?

Looking into it. Probably another special case where an extra small record is allowed (none of the variable parts present).

[David Mathog (mathog)]

Revision 14618 has a patch that allows EMF_illustrator_A4.emf to load. As expected, it was a record type where an optional piece was not present, but an early sanity test for size expected (part) of it to be there.

At this point my test system opens and displays all of your examples, and they (mostly) look OK to me.

If you are still having problems, then please build with -g -O0 and then run in gdb, so a bt or crash dump will tell us something useful.

For the PartialSuccess ones where you said text was missing, did you mean all of the text, or just some of it? They all look OK in Inkscape except Speedometer.emf. That file has two possibly troublesome font declarations, which are:

U_EMR_EXTCREATEFONTINDIRECTW record: 582 type:82 offset: 1679440 rsize: 368 crc32:459EE516
   ihFont: 1
   Font: lfHeight:-150 lfWidth:0 lfEscapement:0 lfOrientation:0 lfWeight:700 lfItalic:0x00 lfUnderline:0x00 lfStrikeOut:0x00 lfCharSet:0x00 lfOutPrecision:0x04 lfClipPrecision:0x00 lfQuality:0x04 lfPitchAndFamily:0x22 lfFaceName:(null)

U_EMR_EXTCREATEFONTINDIRECTW record: 791 type:82 offset: 3499708 rsize: 368 crc32:90FF77CE
   ihFont: 1
   Font: lfHeight:-333 lfWidth:0 lfEscapement:0 lfOrientation:0 lfWeight:400 lfItalic:0x00 lfUnderline:0x00 lfStrikeOut:0x00 lfCharSet:0x00 lfOutPrecision:0x04 lfClipPrecision:0x00 lfQuality:0x04 lfPitchAndFamily:0x22 lfFaceName:Kozuka Gothic Pr6N H

The first doesn't actually specify a font name, and the 2nd specifies a font you may not have. The 2nd one is for the "DxCK"
text. The first one is for the "0" character on the speedometer. Since nothing useful was specified it defaults to Arial, but all the other speeds are in Calibri.

Speedometer.emf uses EMF bitmap transparency tricks which do not work on import in EMF. The two STRETCHDIBITS entries at records 514 and 515 are supposed to put the magnifying glass image over the dial so that it can be seen through. What happens instead is that it places a blocking rectangle underneath, and a nontransparent magnifying glass image in a square. Something else drops a bounding square over the central part of the dial blocking most of it. Not sure which records to that, but you can select those rectangles and delete them. The "button" under the DxCK has a similar transparency issue.

[Alvin Penner (apenner)]

I have compiled Inkscape rev 14618. With this change, the file EMF_Illustrator_a4.emf loads with no error messages. However, the text is missing. The svg file actually contains the correct text, but it is not visible. I am attaching the svg file. I will test the other files shortly.

[Alvin Penner (apenner)]

I have tested the remaining 14 files. They all behave the same as before, nothing has changed.
- wrt the options -g -O0, these options were rejected by btool, so I did a normal compile
- wrt the issue of text, as far as I can tell, all the files are missing all the text.
- attached is a complete backtrace obtained from the file Shape Graph.emf

[Alvin Penner (apenner)]

wrt the file EMF_Illustrator_a4.emf , the problem appears to be the presence of the following transform element in the text tag:

     transform="scale(0)"

[David Mathog (mathog)]

the compiler options "-g -O0" go in build.xml, in the "TARGET : COMPILE" <flags> section.

When EMF_Illustrator_a4.emf is loaded on my test system that transform line does not appear. The one
in the first text tag (for "U") is:

     transform="translate(-0.3125,12.557373)"

[Alvin Penner (apenner)]

I have compiled Inkscape rev 14618 using the options -g -O0

The new backtrace is attached, for the file Shape Graph.emf.

..........................................

C:\InkscapeBZR\inkscape>gdb inkscape.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) symbol-file inkscape.dbg
Reading symbols from C:\InkscapeBZR\inkscape/inkscape.dbg...done.
(gdb) run
Starting program: C:\InkscapeBZR\inkscape/inkscape.exe
[New thread 1992.0xeb8]
[New thread 1992.0xa8c]
[New thread 1992.0xecc]
[New thread 1992.0xfe4]
[New thread 1992.0xd74]
[New thread 1992.0x818]
[New thread 1992.0xc78]
[New thread 1992.0x984]
[New thread 1992.0xa90]
warning: Lowest section in C:\WINDOWS\system32\xpsp2res.dll is .rsrc at 00011000

Program received signal SIGSEGV, Segmentation fault.
0x005cdcd6 in trinfo_append_out (tri=0x30303336,
    src=0x1f5e64 "transform=\"matrix(0.000000,0.000000,-0.000000,-19372393821185
38422281013355813589066806596006108206544641866469688875296882071854586970523398
60192941588828002578315067552939960476293088722936761121555"...)
    at src/extension/internal/text_reassemble.c:204
204 for(match=1,j=0; sub[j] && string[i+j]; j++){
Current language: auto; currently c
(gdb) bt
#0 0x005cdcd6 in trinfo_append_out (tri=0x30303336,
    src=0x1f5e64 "transform=\"matrix(0.000000,0.000000,-0.000000,-19372393821185
38422281013355813589066806596006108206544641866469688875296882071854586970523398
60192941588828002578315067552939960476293088722936761121555"...)
    at src/extension/internal/text_reassemble.c:204
#1 0x005cf6ba in TR_layout_2_svg (tri=0x30303336)
    at src/extension/internal/text_reassemble.c:204
#2 0x36303637 in ?? ()
#3 0x30303336 in ?? ()
#4 0x33303733 in ?? ()
#5 0x34373135 in ?? ()

...

#354 0x302c3030 in ?? ()
#355 0x3030302e in ?? ()
#356 0x2c303030 in ?? ()
#357 0x302e302d in ?? ()
#358 0x30303030 in ?? ()
#359 0x0a222930 in ferror ()
#360 0x00000000 in ?? ()
(gdb)

[David Mathog (mathog)]

Since I cannot reproduce the crash please try

gdb --args path_to_inkscape/inkscape
break text_reassemble.c:202
r

That breakpoint should be at the top of the outer loop in TR_findcasesub. When execution gets to that point
print the values of "*string" and "*sub". Probably the first one is either NULL, a pointer to a random location
in memory, or a pointer to a string which isn't terminated with a '\0' byte. If I had to place a wager it would be on the last case. If the test file isn't simple execution might pass through this routine several times before you hit the one that crashes.

Thanks.

[Alvin Penner (apenner)]

I was not able to get that procedure to work.

I would suggest that you compile Inkscape on a Win32 platform, using a recent devlibs, so that you can diagnose what has gone wrong. There have been a number of changes in devlibs recently, so you will need to use a recent version.

[Alvin Penner (apenner)]

in the file text_reassemble.c it looks as if some improvement can be made by replacing the format %lf with the format %f. For example,

replace
sprintf(obuf,"transform=\"matrix(%lf,%lf,%lf,%lf,%lf,%lf)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc),1.25*x,1.25*y);
with
sprintf(obuf,"transform=\"matrix(%f,%f,%f,%f,%f,%f)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc),1.25*x,1.25*y);

when I make this change, then the scale factors in the transform matrix become correct, that is non-pathological, and most of the crashes in these files are avoided. The text is still not visible, but at least the files do not crash.

[David Mathog (mathog)]

I don't expect to have time to work with this on Windows for a while.

In the meantime, what you say is really odd. %lf and %f are supposed to be the same for all the printf variants (but not scanf). See for instance the thread here which contains quotes from the language standard:

  http://stackoverflow.com/questions/4264127/correct-format-specifier-for-double-in-printf

Since you are seeing a difference between them that suggests the module is being compiled with some standard or include that changes the expected behavior. That is the real problem. What is the compile command for text_reassemble.c on your system? It is in compile.lst at the top of the inkscape directory tree. It will be a very long command something like this:

mingw32-gcc -c -Wall -Wformat -Werror=format-security -Wextra -Wpointer-arith
 -Wcast-align -Wsign-compare -Wswitch -Werror=return-type -Wno-error=pointer-
sign -Wno-error=unused-parameter -Wno-error=unused-but-set-variable
-Wno-error=strict-overflow -Wno-error=write-strings -Wno-error=format
-Wno-error=format-extra-args -O2 -mms-bitfields -fopenmp -DVERSION=\"0.48+dev
el_r13915\" -DHAVE_CONFIG_H -D_INTL_REDIRECT_INLINE -DHAVE_SSL -DRELAYTOOL_SS
L="static const int libssl_is_present=1; static int __attribute__((unused))
libssl_symbol_is_present(char *s){ return 1; }" -DPOPPLER_NEW_GFXFONT
-DGLIBMM_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLU
DES -DGDKMM_DISABLE_DEPRECATED -DGSEAL_ENABLE
(a million -I options here)
 src/extension/internal/text_reassemble.c
-o build/obj/extension/internal/text_reassemble.o

Is yours using a compiler other than mingw32-gcc, or setting a specific language standard?
Perhaps it is using a c++ compiler instead of a c compiler?

To see what is actually going on, perhaps drop the following"test_cos.c" file in the same directory as
text_reassemble.c, and then compile it with the same command line except change the last part to

   test_cos.c -o ./test_cos

#ifdef __cplusplus
extern "C" {
#endif

#include "text_reassemble.h"
#include <libuemf/uemf_utf.h> /* For a couple of text functions. Exact copy from libUEMF. */
#include <float.h>

int main(void){
   double angle=1.2345;
   fprintf(stdout,"cos %lf sin %lf\n",cos(angle),sin(angle));
}

#ifdef __cplusplus
}
#endif

When it is run the expected result is:
cos 0.329993 sin 0.943983

If it comes out different than that, change the compiler by adding "-E" and changing the output to
-o ./test_cos.i

Then look at test_cos.i and see if it has redefined fprintf() or cos() somewhere.

My (not updated) Windows XP build system uses ming32-gcc 4.6.2.

[Alvin Penner (apenner)]

I am using the standard Windows build directly from the website, together with btool, and tdm-gcc 4.6.1

I am not in a position to be able to investigate this any further.

[David Mathog (mathog)]

OK. I will ask somebody who works on devlibs to have a look.

That %lf and %f business is pretty mysterious. I could not make test_cos.c break on a test system
with any of these variants:

gcc -std=c99
gcc -std=gnu89
gcc -std=gnu99
g++ -std=c++98
g++ -std=gnu++98
g++ -std=c++0x
g++ -std=gnu++0x

all emitted the same output, and it was the same when changed from %lf to %f too.
It wouldn't compile with these:

gcc -std=c89
gcc -std=iso9899:199409

because some of the includes use "//" comments.

[David Mathog (mathog)]

valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --log-file=/tmp/vgfi.log src/inkscape

Then load Shape Graph.emf, then exit (this takes about 6 minutes total to complete):

grep reassemble /tmp/vgfi.log
# nothing
grep -i uemf /tmp/vgfi.log
# nothing
grep emf /tmp/vgfi.log \
  | grep cpp \
  | extract -mt -dl '()' -fmt '[-1]' \
  | sort \
  | uniq

gives only

emf-inout.cpp:3546
emf-inout.cpp:3590
emf-inout.cpp:3614
emf-print.cpp:2198

Those are the expected leaks (in code called by those routines, this has not changed in years).
So there is no evidence of uninitialized variables, access violations, or any other related
problems in the EMF code or text_reassemble that would account for what you are seeing on Windows.

[Alvin Penner (apenner)]

Sorry, I'm on Windows, those instructions are like Greek to me, and they do not appear to be relevant.

however, here is an alternative approach. Instead of using the function sprintf, use the function g_sprintf.

So, for example, replace the call:
  sprintf(obuf,"transform=\"matrix(%lf,%lf,%lf,%lf,%lf,%lf)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc),1.25*x,1.25*y);
with the call:
g_sprintf(obuf,"transform=\"matrix(%lf,%lf,%lf,%lf,%lf,%lf)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc),1.25*x,1.25*y);

this has the advantage of keeping the format %lf. It appears to yield exactly the same benefits as the suggestion in comment 24 above, namely a correct transform matrix. In order to use this, you need to declare the header

#include <glib/gprintf.h>

[David Mathog (mathog)]

Re 29. There should not be any difference between sprintf() and g_sprintf(), nor between %lf and %f. That there is tells us that something has gone wrong elsewhere, likely either in the preprocessor related to the devlibs() changes, or possibly in some of my code that precedes this. Post 28 describes the usual steps used on linux to hunt down the latter sort of issues, and the results shown were negative with the current trunk revision. This sort of corruption can be miserably difficult to find with print statements, or even a debugger, because what is corrupted is often parts of the stack, which brings the whole house of cards down.

Unfortunately I have never been able to find an equivalent of valgrind to use for Windows development. The closest was Dr.Memory, but when I tried it several years ago it could not handle Inkscape, it just would not run.

[Alvin Penner (apenner)]

just writing to confirm that these crashes still exist on:

Windows 7 (32 bit), Inkscape 0.91+devel r14629 (Feb 3 2016)
This version was obtained from a 7z file: inkscape-14630-devlibs-51.7z
from the site: http://download.tuxfamily.org/inkscape/

All 10 emf files in the folder InternalErrorCrash lead to a crash.
I would suggest raising the priority of this bug since, for practical purposes, the emf import can no longer be used on Windows, which is the platform where it is most likely to be needed or wanted.
I have had good success in avoiding this crash using comment 29 above.

[David Mathog (mathog)]

Please follow the instructions for bug 14806551 message 30 and post the results here. Since I cannot reproduce the problem you are seeing on my own systems we will have to fall back to this form of remote debugging to work it out. You will need Inkscape release 14660 or higher. Eduard Braun has posted one you may use, there is a link in the other bug thread to his download site.

[David Mathog (mathog)]

Rats, typo'd that bug. It is 1480651, not 551.

[Alvin Penner (apenner)]

two comments:
- first of all, Eduard Braun's builds are 64 bit builds so I cannot use them, because I have a 32 bit machine.
- secondly, why not just implement comment 29, which we know for sure is guaranteed to work. I have implemented this fix and have confirmed that all the files load correctly, including the missing text. I would be more than happy to provide a detailed patch file if you like.

[David Mathog (mathog)]

The reason I'm not going to do what you suggest in 29 is because I believe that it is just papering over the real problem.

I finally bit the bullet and put together a new build environment (devlibs 61) and it does indeed crash on files that open
correctly under linux. Working on it now.

[Alvin Penner (apenner)]

thanks, I was beginning to feel a bit paranoid, being the only one to experience this problem

[David Mathog (mathog)]

Wow, something really strange is going on here. Differences now present between the windows version and the
linux version (with a test file consisting of a single rectangle) include:

1. load emf from command line. No problem on linux. On windows it fails to load and does not even enter the sections of emf code where debug statements have been enabled. Not even the DEBUG statement associated with the very first line of the EMF is emitted.

2. A subsequent load of the test emf on windows from the file menu does enter emf code and the INKSCAPE_DBG_EMF flags are respected. This is really bad - there should be no difference between loading a file from the command line and from the file menu! The SVG file created has all coordinates and widths scaled up by a factor of 1.066667, presumably (1 + 1/15). There is only one MODIFYWORLDTRANSFORM record in the test case, and it is not responsible for this.

3. gdb is working only sporadically, often not allowing break points to be set (it says the file doesn't exist, or the line doesn't exist), and returning backtraces >600 levels deep with no symbols, just numbers.

4. btool links are taking FOREVER, much longer than the last time I worked on Windows. It's the same machine, and the same mingw, so something else must have changed.

[Alvin Penner (apenner)]

try monitoring the transforms that come out of the statements:

sprintf(obuf,"transform=\"matrix(%lf,%lf,%lf,%lf,%lf,%lf)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc),1.25*x,1.25*y);
sprintf(stransform,"transform=\"matrix(%lf,%lf,%lf,%lf,%lf,%lf)\"\n",cos(esc),-sin(esc),sin(esc),cos(esc), 1.25*x,1.25*y);

in the file text_reassemble.c, around line 2030 and line 2180. The transforms are corrupted.

[LucaDC (lucadc)]

1.066666667 = 96/90: related to change of default DPI, maybe?

[David Mathog (mathog)]

As I said before, sprintf() is supposed to accept %lf to format a double. And it does, except in inkscape, which means that the %lf is not the root of the problem.

Unfortunately this appears to be a bug in the Windows build method which causes either sprintf() or the trig functions cos(), sin() to be silently replaced at the link stage.

Using this test program:

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main(void){
  char huge[64000];
  double esc=0;
  printf("esc %lf cos %lf sin %lf -sin %lf -cos %lf\n",
    esc,cos(esc),sin(esc),-sin(esc),-cos(esc));
  sprintf(huge,"esc %lf cos %lf sin %lf -sin %lf -cos %lf\n",
    esc,cos(esc),sin(esc),-sin(esc),-cos(esc));
  printf("%s\n",huge);
  exit(EXIT_SUCCESS);
}

compile either on linux or Windows (mingw) with

gcc -o printf_bug printf_bug.c -lm

and they both emit (as they should)

esc 0.000000 cos 1.000000 sin 0.000000 -sin -0.000000 -cos -1.000000
esc 0.000000 cos 1.000000 sin 0.000000 -sin -0.000000 -cos -1.000000

However, if instead on Windows one links it like one links inkscape, like so:

gcc -c bug_printf.o printf_bug.c
mingw32-g++ -o printf_bug -mconsole -mthreads printf_bug.o -Lc:\progs\devlibs61/ -Lc:\progs\devlibs61/lib -lMagick++ -lMagickCore -laspell -latk-1.0 -latkmm-1.6 -lcairo -lcairomm-1.0 -lcdr-0.1 -lcomdlg32 -lexif -lfontconfig -lfreetype -lgc -lgdi32 -lgdk-win32-2.0 -lgdk_pixbuf-2.0 -lgdkmm-2.4 -lgio-2.0 -lgiomm-2.4 -lglib-2.0 -lglibmm-2.4 -lgobject-2.0 -lgomp -lgsl -lgslcblas -lgthread-2.0 -lgtk-win32-2.0 -lgtkmm-2.4 -liconv -lintl -ljpeg -llcms2 -lm -lmscms -lpango-1.0 -lpangocairo-1.0 -lpangoft2-1.0 -lpangomm-1.4 -lpangowin32-1.0 -lpng -lpoppler -lpoppler-glib -lpopt -lpotrace -lpthreadGC2 -lrevenge-0.0 -lrevenge-stream-0.0 -lsigc-2.0 -ltiff -lvisio-0.1 -lwpd-0.9 -lwpd-stream-0.9 -lwpg-0.2 -lws2_32 -lz c:\progs\devlibs61/bin/libexslt.dll c:\progs\devlibs61/bin/libxml2.dll c:\progs\devlibs61/bin/libxslt.dll

then the output becomes:

esc 0.000000 cos 0.000000 sin 0.000000 -sin 0.000000 -cos 0.000000
esc 0.000000 cos 0.000000 sin 0.000000 -sin 0.000000 -cos 0.000000

It doesn't fail in quite the same way as within the program, but that probably just indicates whatever happens
to be nearby in memory is different in the two situations.

Going to

mingw32-g++ -o printf_bug printf_bug.o -lm

produces a binary which works properly.

So apparently one of those libraries, or perhaps a combination of them, is doing something bad. I will try to narrow it down.

[David Mathog (mathog)]

The problem is poppler. This command is enough to break the test case.

mingw32-g++ -o printf_bug printf_bug.o -Lc:\progs\devlibs61/lib -lpoppler

[jazzynico (jazzynico)]

Not sure it's related to the latest Poppler update (or at least it's not the only cause). I've just tried to load the file attached comment #1 with older Inkscape versions, and:
* it works with rev. 14039 (March 2015),
* but fails with rev. 14274 (August 2015).

 Both versions on Windows XP, devlibs r53 with Poppler-0.12.1.

[Alvin Penner (apenner)]

the problem appears to have shown up in two stages:
using the 10 files in the archive InternalErrorCrash.zip, I get the results:
using 7z files from: http://download.tuxfamily.org/inkscape/

- Inkscape 0.91 r13725 (Jan 30 2015)
  all 10 files load, with text

- Inkscape 0.91+devel (Dec 7 2015), from the file inkscape-14506.7z
  7 files load normally, 3 files fail with the message "failed to load", no crashes

- Inkscape 0.91+devel (Jan 14 2016), from the file inkscape-14574.7z
  8 files crash with the message: "Inkscape encountered an internal error"
  2 files fail with the message: "Failed to load"

[David Mathog (mathog)]

Since there is absolutely no reason that merely linking to poppler should break the printf calls in the test in post 40 I wouldn't make any assumptions that minor code changes elsewhere in Inkscape will not dramatically alter the number of files it can open. Poppler in devlibs61 on Windows is clearly stepping on things it should not (the printf functions) and who knows why that is happening. The poppler in devlibs53 does not have this problem:

mingw32-g++ -o printf_bug printf_bug.o -Lc:\progs\devlibs53/lib -lpoppler
printf_bug
esc 0.000000 cos 1.000000 sin 0.000000 -sin 0.000000 -cos -1.000000
esc 0.000000 cos 1.000000 sin 0.000000 -sin 0.000000 -cos -1.000000

Let's get poppler to not break printf() and then worry about whatever other bugs there may be.

[Alvin Penner (apenner)]

    I would like to argue in favor of a more pragmatic approach, since I do not think it is feasible for us to sit and wait for this to be fixed in poppler. I am willing to stipulate that the problem probably lies in poppler. For example the devlibs rev 56 occurred on Jan 8, which is in the right timeframe to explain the problem. However I do not think that it is our responsibility to fix this problem in poppler, nor is it even likely to be feasible to do so, unless we have a poppler expert in-house. It is our responsibility to report the problem to the poppler group, and then move on. It is not like the situation in lib2geom, ref Bug 1492153, where it was reasonable for us to assume that we could fix this properly in-house, thanks Liam.
    The current problem appears to be rather abstruse. For example, search the entire inkscape code base in \src\ and you will find only two occurrences of the format %lf. Both are related to either wmf or emf. One occurrence is in metafile-print.cpp where it is used in sscanf. The other occurrence is in text_reassamble.c, where it is used many times in printf and sprintf. The problems caused by these usages can be fixed very effectively using either comment 24 or 29, which use either g_sprintf or %f as an alternative.
    I would suggest that we formally report this as a bug to poppler, then wait for a week, and then fix it ourselves in Inkscape, if we get no response. Precisely which fix we implement can be based on which you think is more politically acceptable, since this is ultimately a political problem, not a technical one. What I mean by that is that the difference between %lf and %f, or between sprintf and g_sprintf, is no practical significance as far as I know, so the decision cannot be made on purely technical grounds. If a difference does exist in principle, then it should be stated here explicitly so we can make a better decision.

[David Mathog (mathog)]

In a mingw/msys window do:

 strings /c/progs/devlibs53/lib/libpoppler.dll.a | grep printf
 strings /c/progs/devlibs61/lib/libpoppler.dll.a | grep printf

This shows that the newer version has its own copies of the printf()
series of functions, but the older one does not. Like this:

fprintf
_fprintf
__imp__fprintf

On linux (Ubuntu 14.04) libpoppler also has redefines these language standard functions:

strings /usr/lib/i386-linux-gnu/libpoppler.so | grep -i fprintf
__fprintf_chk

strings /usr/lib/i386-linux-gnu/libpoppler.a | grep -i fprintf
__fprintf_chk

and uses the same name as libc

strings /lib/i386-linux-gnu/libc.so.6 | grep fprintf
__fprintf_chk

Yet there is no problem using them on Linux.

Let me bounce this off the poppler mailing list and see if this is a known issue.

[David Mathog (mathog)]

Hmm. Just unpacked and looked through current poppler source and it does not define sprintf(). Those strings in the last post must be use of, not definition of. Now I don't have a good explanation, other than clearly poppler is doing it.

Post sent to poppler list, waiting for a response.

[David Mathog (mathog)]

Bug 1552913 filed in devlibs.

https://bugs.launchpad.net/inkscape-devlibs/+bug/1552913

See that thread for more tests. I was able to demonstrate error messages from Dr. Memory in what seem like the appropriate places when a test program was run that was linked with libpoppler. These messages did not appear when it was linked without libpoppler and run the same way. This is consistent with a bug in libpoppler, at least the one in devlibs61.

[jazzynico (jazzynico)]

Just tested with an updated Poppler lib (see Bug #1552913 for details), and all the files from comment #10 now import as expected, with no crash, error message or console warning.

But I'm not very happy with the workaround I had to apply (a bit dirty IMHO), and I'm not 100% sure there's no risk of regressions. Suggestion on a more elegant fix are welcome!

[David Mathog (mathog)]

Revision 14699 just created. It should resolve this issue.

As discussed in the devlibs bug thread, mingw is not fully C99 compliant. It interprets
"%lf" as a synonym for "%Lf" which means "long double". Depending on which print() functions actually get used it may use one that is looking for an 80 bit long double, when only 64 bits are present. Mayhem follows. If instead it uses one looking for a 64 bit long double everything works as expected. By accident. Controlling which one is used is messy.

The patch takes out all the "%lf". So Alvin was right, that format specifier had to go. The code wasn't broken though, the Windows build environment was. Or at least it wasn't ANSI compatible.

[jazzynico (jazzynico)]

Fix confirmed on Windows 7, Inkscape trunk rev. 14703.
Thanks!