Re: [poppler] Poppler provided printf() functions on Windows not language compliant
Hello, Am 05.03.2016 um 02:51 schrieb mathog: > mingwenv > mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug > printf_bug.c -Lc:\progs\devlibs61/lib -lpoppler > "C:\Program Files\Dr. Memory\bin\drmemory.exe" -logdir C:/temp/logs -- > printf_bug > Error #1: UNINITIALIZED READ: reading 0x00220378-0x0022037a 2 byte(s) > within 0x00220370-0x0022037a > # 0 libpoppler-58.dll!__pformat_cvt [../../mingw/include/math.h:361] > # 1 libpoppler-58.dll!__pformat_float > [../../mingw/mingwex/stdio/pformat.c:800] > # 2 libpoppler-58.dll!__mingw_pformat > [../../mingw/mingwex/stdio/pformat.c:2047] > # 3 libpoppler-58.dll!__mingw_vprintf > [../../mingw/mingwex/stdio/vprintf.c:61] > # 4 libpoppler-58.dll!printf > [../../../../src/gcc-4.6.1/libgcc/../gcc/config/i386/cygwin.asm:125] > # 5 main [C:\progs\inkscape_trunk/printf_bug.c:8] This looks like you are linking libgcc statically, but load libpoppler dynamically? If so, couldn't it be that global data structures from the static library and the dependencies on libgcc in libpoppler collide for example if the versions do not match? Have you tried to replace with libpoppler with any other dynamic link library from the devlibs collection that references printf? Have you tried not to link statically with libgcc? Best regards, Adam. signature.asc Description: OpenPGP digital signature ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
On Fri, Mar 04, 2016 at 06:06:49PM -0800, mathog wrote: > Since this is at least a problem in the libpoppler version in devlibs, a bug > has been filed here. > > https://bugs.launchpad.net/inkscape-devlibs/+bug/1552913 > > At this point I don't know if the issue is how this particular one was > built, or some problem poppler has in general on Windows. (It doesn't seem > to have this issue on Linux.) > > Regards, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech From what I can tell looking at dissambly, linking with libpoppler will cause a mingw printf function to be used, otherwise a printf from msvcrt is used. ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
> To: poppler@lists.freedesktop.org > Date: Fri, 4 Mar 2016 17:51:24 -0800 > From: mat...@caltech.edu > Subject: Re: [poppler] Poppler provided printf() functions on Windows not > language compliant > > On 04-Mar-2016 15:27, William Bader wrote: > > Do you have any tools to track down bad memory accesses similar to > > valgrind on Linux? > > Well, I had tried Dr. Memory previously on Inkscape and it died a > horrible death trying to handle all of those memory structures. However > this test program is tiny, so let's go with that. > > Installs current release of Dr. Memory on 32 bit XP machine. > > In DOS shell > > mingwenv > mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug > printf_bug.c -Lc:\progs\devlibs61/lib -lpoppler > "C:\Program Files\Dr. Memory\bin\drmemory.exe" -logdir C:/temp/logs -- > printf_bug > > This logged several errors in libpoppler > > or > > mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug > printf_bug.c > "C:\Program Files\Dr. Memory\bin\drmemory.exe" -logdir C:/temp/logs -- > printf_bug > > this logged no errors. > > > Jason Crain suggested stepping in with a debugger. Tried that and it > didn't help, the libpoppler is not compiled with -g, there are no > symbols. > > These are the errors from the first run mentioned above. It is not very > helpful because libpoppler is built without debugging symbols. Sorry, > this will probably wrap: > > Dr. Memory version 1.9.0 build 4 built on Oct 2 2015 13:13:14 > Dr. Memory results for pid 2056: "printf_bug.exe" > Application cmdline: "printf_bug" > Recorded 116 suppression(s) from default C:\Program files\Dr. > Memory\bin\suppress-default.txt > > Error #1: UNINITIALIZED READ: reading 0x00220378-0x0022037a 2 byte(s) > within 0x00220370-0x0022037a > # 0 libpoppler-58.dll!__pformat_cvt [../../mingw/include/math.h:361] > # 1 libpoppler-58.dll!__pformat_float > [../../mingw/mingwex/stdio/pformat.c:800] > # 2 libpoppler-58.dll!__mingw_pformat > [../../mingw/mingwex/stdio/pformat.c:2047] > # 3 libpoppler-58.dll!__mingw_vprintf > [../../mingw/mingwex/stdio/vprintf.c:61] > # 4 libpoppler-58.dll!printf > [../../../../src/gcc-4.6.1/libgcc/../gcc/config/i386/cygwin.asm:125] > # 5 main > [C:\progs\inkscape_trunk/printf_bug.c:8] > Note: @0:00:01.328 in thread 3760 > Note: instruction: fld0x20(%esp) -> %st0 > > Error #2: UNINITIALIZED READ: reading 0x00220374-0x0022037a 6 byte(s) > within 0x00220370-0x0022037a > # 0 libpoppler-58.dll!__pformat_cvt [../../mingw/include/math.h:361] > # 1 libpoppler-58.dll!__pformat_float > [../../mingw/mingwex/stdio/pformat.c:800] > # 2 libpoppler-58.dll!__mingw_pformat > [../../mingw/mingwex/stdio/pformat.c:2047] > # 3 libpoppler-58.dll!__mingw_vprintf > [../../mingw/mingwex/stdio/vprintf.c:61] > # 4 libpoppler-58.dll!printf > [../../../../src/gcc-4.6.1/libgcc/../gcc/config/i386/cygwin.asm:125] > # 5 main > [C:\progs\inkscape_trunk/printf_bug.c:10] > Note: @0:00:01.437 in thread 3760 > Note: instruction: fld0x20(%esp) -> %st0 > > === > FINAL SUMMARY: > > DUPLICATE ERROR COUNTS: > Error # 2: 2 > > SUPPRESSIONS USED: > > ERRORS FOUND: >0 unique, 0 total unaddressable access(es) >2 unique, 3 total uninitialized access(es) >0 unique, 0 total invalid heap argument(s) >0 unique, 0 total GDI usage error(s) >0 unique, 0 total handle leak(s) >0 unique, 0 total warning(s) >0 unique, 0 total, 0 byte(s) of leak(s) >0 unique, 0 total, 0 byte(s) of possible leak(s) > ERRORS IGNORED: >4 unique, 5 total, 11360 byte(s) of still-reachable > allocation(s) > (re-run with "-show_reachable" for details) > Details: c:\temp\logs\DrMemory-printf_bug.exe.2056.000\results.txt > > Guess I should report it as a bug. Although I am not sure if it is a > devlibs61 problem or an underlying issue in poppler. > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech I think that the log above does not show the error that caused the crash. "Uninitialized access" warnings are common false positives in memory checkers. They can happen when you copy a structure that has not had every byte of every field initialized. Dr. Memory even comments on that at http://drmemory.org/docs/page_uninit.html An access to an invalid address can cause a crash, but reading an uninitialized variable should not directly cause a crash. If the uninitialized variable was a length or a pointer, using the value could lead to an invalid access, and that could cause a crash, but through an an invalid access, and the log does not show any "unaddressable access" errors. Also, the stack trace shows pformat.c and vprintf.c. Those are not part of
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
Since this is at least a problem in the libpoppler version in devlibs, a bug has been filed here. https://bugs.launchpad.net/inkscape-devlibs/+bug/1552913 At this point I don't know if the issue is how this particular one was built, or some problem poppler has in general on Windows. (It doesn't seem to have this issue on Linux.) Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
On 04-Mar-2016 15:27, William Bader wrote: Do you have any tools to track down bad memory accesses similar to valgrind on Linux? Well, I had tried Dr. Memory previously on Inkscape and it died a horrible death trying to handle all of those memory structures. However this test program is tiny, so let's go with that. Installs current release of Dr. Memory on 32 bit XP machine. In DOS shell mingwenv mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug printf_bug.c -Lc:\progs\devlibs61/lib -lpoppler "C:\Program Files\Dr. Memory\bin\drmemory.exe" -logdir C:/temp/logs -- printf_bug This logged several errors in libpoppler or mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug printf_bug.c "C:\Program Files\Dr. Memory\bin\drmemory.exe" -logdir C:/temp/logs -- printf_bug this logged no errors. Jason Crain suggested stepping in with a debugger. Tried that and it didn't help, the libpoppler is not compiled with -g, there are no symbols. These are the errors from the first run mentioned above. It is not very helpful because libpoppler is built without debugging symbols. Sorry, this will probably wrap: Dr. Memory version 1.9.0 build 4 built on Oct 2 2015 13:13:14 Dr. Memory results for pid 2056: "printf_bug.exe" Application cmdline: "printf_bug" Recorded 116 suppression(s) from default C:\Program files\Dr. Memory\bin\suppress-default.txt Error #1: UNINITIALIZED READ: reading 0x00220378-0x0022037a 2 byte(s) within 0x00220370-0x0022037a # 0 libpoppler-58.dll!__pformat_cvt [../../mingw/include/math.h:361] # 1 libpoppler-58.dll!__pformat_float [../../mingw/mingwex/stdio/pformat.c:800] # 2 libpoppler-58.dll!__mingw_pformat [../../mingw/mingwex/stdio/pformat.c:2047] # 3 libpoppler-58.dll!__mingw_vprintf [../../mingw/mingwex/stdio/vprintf.c:61] # 4 libpoppler-58.dll!printf [../../../../src/gcc-4.6.1/libgcc/../gcc/config/i386/cygwin.asm:125] # 5 main [C:\progs\inkscape_trunk/printf_bug.c:8] Note: @0:00:01.328 in thread 3760 Note: instruction: fld0x20(%esp) -> %st0 Error #2: UNINITIALIZED READ: reading 0x00220374-0x0022037a 6 byte(s) within 0x00220370-0x0022037a # 0 libpoppler-58.dll!__pformat_cvt [../../mingw/include/math.h:361] # 1 libpoppler-58.dll!__pformat_float [../../mingw/mingwex/stdio/pformat.c:800] # 2 libpoppler-58.dll!__mingw_pformat [../../mingw/mingwex/stdio/pformat.c:2047] # 3 libpoppler-58.dll!__mingw_vprintf [../../mingw/mingwex/stdio/vprintf.c:61] # 4 libpoppler-58.dll!printf [../../../../src/gcc-4.6.1/libgcc/../gcc/config/i386/cygwin.asm:125] # 5 main [C:\progs\inkscape_trunk/printf_bug.c:10] Note: @0:00:01.437 in thread 3760 Note: instruction: fld0x20(%esp) -> %st0 === FINAL SUMMARY: DUPLICATE ERROR COUNTS: Error # 2: 2 SUPPRESSIONS USED: ERRORS FOUND: 0 unique, 0 total unaddressable access(es) 2 unique, 3 total uninitialized access(es) 0 unique, 0 total invalid heap argument(s) 0 unique, 0 total GDI usage error(s) 0 unique, 0 total handle leak(s) 0 unique, 0 total warning(s) 0 unique, 0 total, 0 byte(s) of leak(s) 0 unique, 0 total, 0 byte(s) of possible leak(s) ERRORS IGNORED: 4 unique, 5 total, 11360 byte(s) of still-reachable allocation(s) (re-run with "-show_reachable" for details) Details: c:\temp\logs\DrMemory-printf_bug.exe.2056.000\results.txt Guess I should report it as a bug. Although I am not sure if it is a devlibs61 problem or an underlying issue in poppler. Thanks, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
On Fri, Mar 04, 2016 at 01:58:54PM -0800, mathog wrote: > On 04-Mar-2016 13:49, mathog wrote: > >In tracking down a bug in Inkscape here: > > > > https://bugs.launchpad.net/inkscape/+bug/1538361 > > > >it was discovered that the version of Poppler in devlibs61 appears to > >provide its own printf() functions, which replace the usual ones > > Hmm, or not. Downloaded and unpacked poppler-0.41.0 and found that > > grep -R sprintf . > > did not turn up any code that defines a new function. So now I'm really > mystified. > How would linking in a static libpoppler break an applications' use of a > printf() function if it doesn't define a new one? > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech I'm not familiar with compiling for mingw or devlibs, but I'd be curious to see if you run that test program in a debugger and step into the printf function or try the command "info symbol printf" from gdb, to see where the printf function actually goes. ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
> To: poppler@lists.freedesktop.org > Date: Fri, 4 Mar 2016 13:58:54 -0800 > From: mat...@caltech.edu > Subject: Re: [poppler] Poppler provided printf() functions on Windows not > language compliant > > On 04-Mar-2016 13:49, mathog wrote: > > In tracking down a bug in Inkscape here: > > > > https://bugs.launchpad.net/inkscape/+bug/1538361 > > > > it was discovered that the version of Poppler in devlibs61 appears to > > provide its own printf() functions, which replace the usual ones > > Hmm, or not. Downloaded and unpacked poppler-0.41.0 and found that > > grep -R sprintf . > > did not turn up any code that defines a new function. So now I'm really > mystified. > How would linking in a static libpoppler break an applications' use of a > printf() function if it doesn't define a new one? > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech Do you have any tools to track down bad memory accesses similar to valgrind on Linux? Maybe a bug somewhere else is trashing a stdio data structure. I did some MSDOS programming in the 80's, and I remember that stdio was one of the first things in memory, so writes to null pointers would sometimes make stdio fail in strange ways. Also, if the crash is in sprintf() and not printf(), have you double checked that the receiving buffer is large enough? Maybe the Windows %lf writes a longer string than you expected. Using snprintf() is safer. Regards, William ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
> To: poppler@lists.freedesktop.org
> Date: Fri, 4 Mar 2016 13:49:38 -0800
> From: mat...@caltech.edu
> Subject: [poppler] Poppler provided printf() functions on Windows not
> language compliant
>
> In tracking down a bug in Inkscape here:
>
>https://bugs.launchpad.net/inkscape/+bug/1538361
>
> it was discovered that the version of Poppler in devlibs61 appears to
> provide its own printf() functions, which replace the usual ones, and
> that these mishandle this case:
>
> double val=0.0;
> printf("%lf\n",val);
poppler has classes that have member functions called printf() but I think that
poppler does not redefine the printf() in the global name space. (I'm not a
poppler developer. Someone will probably correct me later if I am mistaken.)
The stack traces in https://bugs.launchpad.net/inkscape/+bug/1538361 do not
show any symbol names.
Can you link Inkscape with a build of poppler that was compiled with -g to
identify the location of the replacement printf()?
Inside a git clone of poppler,
git grep printf | grep '\.\.\.'
returns the lines below. The only definitions of printf() are
FileOutStream::printf() and QIODeviceOutStream::printf(), neither of which
should affect Inkscape's calls to the stdio printf() in the global name space.
NEWS: * Use error() instead of fprintf(stderr, ...) in Annot::layoutText
glib/demo/find.c: str = g_strdup_printf ("Searching ... (%d%%)",
poppler/Stream.cc:void FileOutStream::printf(const char *format, ...)
poppler/Stream.h: virtual void printf (const char *format, ...)
GCC_PRINTF_FORMAT(2,3) = 0;
poppler/Stream.h: virtual void printf (const char *format, ...);
qt4/src/poppler-qiodeviceoutstream-private.h:virtual void printf(const char
*format, ...);
qt4/src/poppler-qiodeviceoutstream.cc:void QIODeviceOutStream::printf(const
char *format, ...)
qt5/src/poppler-qiodeviceoutstream-private.h:virtual void printf(const char
*format, ...);
qt5/src/poppler-qiodeviceoutstream.cc:void QIODeviceOutStream::printf(const
char *format, ...)
You noticed that "nm" and "strings" both show "printf" in libpoppler, but
poppler calls printf() for some error messages, so you could have found a call
to printf() instead of a redefinition of printf(). Can you repeat the scan
using a tool that tells whether the symbol table entry is a reference or a
declaration?
For example, with a simple hello world program in C on Linux,
$ cc -c hello.c
$ nm hello.o
T main <- T means a declaration (T = location is in the text
(code) section)
U puts <- U means a reference (U = undefined)
If you can demonstrate conclusively that it is a bug in poppler, can you enter
a bug report at bugs.freedesktop.org ?
Regards, William
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
On 04-Mar-2016 13:49, mathog wrote: In tracking down a bug in Inkscape here: https://bugs.launchpad.net/inkscape/+bug/1538361 it was discovered that the version of Poppler in devlibs61 appears to provide its own printf() functions, which replace the usual ones Hmm, or not. Downloaded and unpacked poppler-0.41.0 and found that grep -R sprintf . did not turn up any code that defines a new function. So now I'm really mystified. How would linking in a static libpoppler break an applications' use of a printf() function if it doesn't define a new one? Thanks, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
