Re: [poppler] Poppler provided printf() functions on Windows not language compliant
> jazzynico posted a version as an attachment for message 6 here: > > https://bugs.launchpad.net/inkscape-devlibs/+bug/1552913 I forgot to add to the previous email that "nm libpoppler-58.dll | grep vfprintf | sort -u" returns 6a2df964 T ___mingw_vfprintf 6a300388 T _vfprintf 6a300388 t .text$vfprintf 6a7f1d48 N .debug_frame$vfprint and nm shows a sequence 6a2df33c T ___main 6a2e2f78 t ___mbrtowc_cp 6a2df4cc T ___mingw_TLScallback 6a2e1084 T ___mingw_pformat 6a2df938 T ___mingw_snprintf 6a2df964 T ___mingw_vfprintf 6a2df998 T ___mingw_vprintf 6a2dfbb4 T ___mingw_vsnprintf 6a2df9d0 T ___mingw_vsprintf I think that these are all part of the mechanics of creating a dll with COFF. The symbols are too close together to have any significant amount of code. I think that one of the differences between ELF and COFF is that ELF dedicates a cpu register to support position independent code. At least on unix, COFF shared objects have to be preconfigured to load at a fixed address. You have to make stubs with import modules for each library (which might be one reason that some maintainers complain whenever a poppler release changes the external API of libpoppler). "nm libpoppler-58.dll" has a section of links to import stubs. The lines below are an example. "I" means an indirect reference. 6a3c56f0 I __imp__cos 6a3c56f4 I __imp__exit 6a3c56f8 I __imp__fclose 6a3c56fc I __imp__fflush 6a3c5700 I __imp__fgetc 6a3c5704 I __imp__fgetpos 6a3c5708 I __imp__floor It looks like libpoppler is requesting all of the *printf functions from mingw but the rest of stdio from msvcrt. The link below says that mingw replaces the stdio libraries because the msvcrt versions are not ANSI compatible and that you can force the msvcrt versions by compiling with -D__USE_MINGW_ANSI_STDIO=0 or by not using compile options like -ansi or -posix that set __STRICT_ANSI__, Maybe the devlib people recently changed the compile options that they use to build poppler. http://mingw-users.1079350.n2.nabble.com/mingw-vfprintf-question-td5445899.html 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: williamba...@hotmail.com > Subject: RE: [poppler] Poppler provided printf() functions on Windows not > language compliant > Date: Sun, 6 Mar 2016 13:18:49 -0800 > From: mat...@caltech.edu > CC: poppler@lists.freedesktop.org > > On 06-Mar-2016 12:22, William Bader wrote: > > > Can you add -v to the compile command to show the full link line? g++ > > adds a number of libraries automatically, and probably mingw adds some > > additional Windows libraries. ... > COMPILER_PATH=c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/;c:/progs/mingw/bin/../libexec/gcc/;c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ > LIBRARY_PATH=c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/;c:/progs/mingw/bin/../lib/gcc/;c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib/;c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../ > COLLECT_GCC_OPTIONS='-v' '-o' 'printf_bug.exe' '-LC:\progs\devlibs61/lib' > '-shared-libgcc' '-mtune=i386' '-march=i386' > c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe -Bdynamic > -u ___register_frame_info -u ___deregister_frame_info -o pri > ntf_bug.exe c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../crt2.o > c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/crtbegin.o -LC:\ > progs\devlibs61/lib -Lc:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2 > -Lc:/progs/mingw/bin/../lib/gcc -Lc:/progs/mingw/bin/../lib/gcc/mi > ngw32/4.6.2/../../../../mingw32/lib > -Lc:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../.. > C:\DOCUME~1\david\LOCALS~1\Temp\cco5h1f7. > o -lpoppler -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex > -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_ > s -lgcc -lmoldname -lmingwex -lmsvcrt > c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o The collect2 command line does the linking. https://gcc.gnu.org/onlinedocs/gccint/Collect2.html It pulls in both the mingw32 library and the msvcrt library. I think that the problem is that you are getting part of stdio from one library and part from another, and they are not compatible. Compile once with -c so you have the .o file of your test program, and then try running the link without -lmsvcrt to see what comes up undefined. That might give a clue to what the link is pulling from msvcrt that might be incompatible with mingw32. I haven't used mingw enough to know whether it is supposed to get stdio from libmingw32 or libmsvcrt. I googled libmingw32 to see what might be in it, and I found the link below that mentions a conflict between mingw32 and a Windows library. https://forum.qt.io/topic/27564/adding-libcmt-lib-conflicts-with-libmingw32-a-default-lib/2 > jazzynico posted a version as an attachment for message 6 here: > > https://bugs.launchpad.net/inkscape-devlibs/+bug/1552913 I looked at it. I have Fedora 23 Linux. Neither nm or objdump could open it, but ar could unpack libpoppler.dll.a, and then I could run .o files (in i386 COFF format) through strings. I found a reference to printf in d006434.o, and a reference to sprintf in d006436.o, but those modules are so small that they are probably just relocation entries rather than code. I could also run nm on libpoppler-58.dll. Dynamic linking is trickier to implement in COFF than in ELF and takes more work to set up. I think that the printf and sprintf code in libpoppler is just a stub for the dynamic linker. Someone with more experience with mingw might know for sure. 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 06-Mar-2016 12:22, William Bader wrote: Can you add -v to the compile command to show the full link line? g++ adds a number of libraries automatically, and probably mingw adds some additional Windows libraries. This is going to wrap I'm pretty sure that the cut/paste from the DOS window is going to add extra EOL characters. Anyway, here it is: C:\progs\inkscape_trunk>g++ -v printf_bug.c -o printf_bug -LC:\progs\devlibs61/lib -lpoppler Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 -- enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=ming w32 --prefix=/mingw Thread model: win32 gcc version 4.6.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'printf_bug.exe' '-LC:\progs\devlibs61/lib' '-shared-libgcc' '-mtune=i386' '-march=i386' c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/cc1plus.exe -quiet -v -iprefix c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/ printf_ bug.c -quiet -dumpbase printf_bug.c -mtune=i386 -march=i386 -auxbase printf_bug -version -o C:\DOCUME~1\david\LOCALS~1\Temp\cck9OGvz .s GNU C++ (GCC) version 4.6.2 (mingw32) compiled by GNU C version 4.6.2, GMP version 5.0.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../mingw32/include" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/include/c++" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/include/c++/mingw32" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/include/c++/backward" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../include" ignoring duplicate directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/include-fixed" ignoring nonexistent directory "c:/progs/mingw/lib/gcc/../../lib/gcc/mingw32/4.6.2/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++ c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/mingw32 c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/backward c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/include c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include c:\progs\mingw\bin\../lib/gcc/mingw32/4.6.2/include-fixed End of search list. GNU C++ (GCC) version 4.6.2 (mingw32) compiled by GNU C version 4.6.2, GMP version 5.0.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f7eb4168c2cf10318cc29da8d23b7f3c COLLECT_GCC_OPTIONS='-v' '-o' 'printf_bug.exe' '-LC:\progs\devlibs61/lib' '-shared-libgcc' '-mtune=i386' '-march=i386' c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/as.exe -o C:\DOCUME~1\david\LOCALS~1\Temp\cco5h1f7.o C:\DOCUME~ 1\david\LOCALS~1\Temp\cck9OGvz.s COMPILER_PATH=c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/;c:/progs/mingw/bin/../libexec/gcc/;c:/progs/mingw/bin/../lib/gcc/ming w32/4.6.2/../../../../mingw32/bin/ LIBRARY_PATH=c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/;c:/progs/mingw/bin/../lib/gcc/;c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2 /../../../../mingw32/lib/;c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../ COLLECT_GCC_OPTIONS='-v' '-o' 'printf_bug.exe' '-LC:\progs\devlibs61/lib' '-shared-libgcc' '-mtune=i386' '-march=i386' c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe -Bdynamic -u ___register_frame_info -u ___deregister_frame_info -o pri ntf_bug.exe c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../crt2.o c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/crtbegin.o -LC:\ progs\devlibs61/lib -Lc:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2 -Lc:/progs/mingw/bin/../lib/gcc -Lc:/progs/mingw/bin/../lib/gcc/mi ngw32/4.6.2/../../../../mingw32/lib -Lc:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/../../.. C:\DOCUME~1\david\LOCALS~1\Temp\cco5h1f7. o -lpoppler -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_ s -lgcc -lmoldname -lmingwex -lmsvcrt c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o Once you have the full link line, you can paste it into a script and try removing Windows libraries to see what ends up undefined. Also, was your poppler dll built with the same mingw version that you have installed on your PC? You might be able to use "strings" or a good editor to search for "GCC" in
Re: [poppler] Poppler provided printf() functions on Windows not language compliant
> To: poppler@lists.freedesktop.org > Date: Sun, 6 Mar 2016 11:22:10 -0800 > From: mat...@caltech.edu > Subject: Re: [poppler] Poppler provided printf() functions on Windows not > language compliant > > On 04-Mar-2016 23:39, Adam Reichold wrote: > >> mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug > >> printf_bug.c -Lc:\progs\devlibs61/lib -lpoppler > > > 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? I think that libgcc might be related to the problem. Maybe something in libpoppler uses something in the Windows C library that is not in the libraries that are part of mingw. The poppler configure script searches for a lot of functions, and maybe it discovered a function in a Windows library, and calling that function brings in something in the Windows stdio implementation that conflicts with the version in mingw's libraries. Can you add -v to the compile command to show the full link line? g++ adds a number of libraries automatically, and probably mingw adds some additional Windows libraries. Once you have the full link line, you can paste it into a script and try removing Windows libraries to see what ends up undefined. Also, was your poppler dll built with the same mingw version that you have installed on your PC? You might be able to use "strings" or a good editor to search for "GCC" in the poppler dll. The stack trace that you send a few days ago had lines that started something like poppler.dll!printf.o. Does that mean that parts of libc are embedded in poppler.dll? Can you post your poppler.dll? I am not sure if Linux objdump can parse it, but it would be interesting to see if that library has more than just poppler code. 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 23:39, Adam Reichold wrote: mingw32-g++ -O0 -ggdb -static-libgcc -static-libstdc++ -o printf_bug printf_bug.c -Lc:\progs\devlibs61/lib -lpoppler 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? The Dr. Memory instructions said to add those two static flags. The problem is evident without them, it just cannot be run in Dr. Memory. The " -Lc:\progs\devlibs61/lib -lpoppler " part was selected out of the original Inkscape compile line, which had many, many other libraries linked in. These were eliminated in a binary search, testing at each step to see if the bug was still present. That showed that linking in poppler was enough to trigger this issue. The devlibs people tell me that that the 64 bit of Poppler does not have this problem, it is specific for the 32 bit build. 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
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
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
