Created attachment 851295 [details] Dependency walker showing missing sprintf_s Description of problem: I deploy an application built with mingw32(-qt5). When starting the application, it gives an error that it cannot load the Qt platform plugin "windows", and the available platform plugins are "minimal, windows". Using the dependency walker shows that libEGL.dll is trying to use sprintf_s, which does not exist in msvcrt.dll. See the attached screenshot (image001.png). When trying a newer build of the mingw{32,64}-angleproject packages from http://koji.fedoraproject.org/koji/buildinfo?buildID=443841, I get a different error that vsprintf_s cannot be found. The dependency walker then shows that libglesv2.dll needs vsprintf_s. See the second attached screenshot. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Install Qt5 application to Windows XP or Server 2003. 2. Run the application. Actual results: Error message will display. Expected results: No error message and application runs. Additional info:
Created attachment 851296 [details] Dependency walker showing missing vsprintf_s
When trying the DLLs from Fedora 20, it is the same as the second case above (vsprintf_s is not found by libglesv2.dll).
These errors appear to me as well (Fedora 20 x86_64, mingw32-qt5, running on Windows XP). I tried this application: https://qt-project.org/doc/qt-5.0/qtgui/openglwindow.html However these errors only apply to Qt5 GUI applications. Does the application work for you on Windows 7? Running an application on Windows 7 (32 bit) also does not work for me, Qt5Gui.dll is crashing. According to Dependency Walker, IEShims.dll is missing, but also copying it from "Program files/Internet Explorer" did not resolve the issue. Apparently some dll functions are missing. On Wine it does not work either, Qt5Gui crashes with the following output: fixme:system:SetProcessDPIAware stub! fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:d3d9:D3DPERF_GetStatus (void) : stub wine: Unhandled page fault on read access to 0x00000004 at address 0x720cf0 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x00720cf0). It seems currently only OpenGL builds of mingw32-qt5 do work.
Created attachment 852318 [details] Screenshot of errors in DependencyWalker running a Qt5 Gui app
Created attachment 852319 [details] Screenshot of errors in DependencyWalker running a Qt5 Gui app, provided IEShims.dll IEShims.dll copied from "C:\Program Files\Internet Explorer" to working directory.
Created attachment 852320 [details] Backtrace and log of Wine running a crashing Qt5 Gui app
(In reply to max.mail from comment #3) > Running an application on Windows 7 (32 bit) also does not work for me, > Qt5Gui.dll is crashing. According to Dependency Walker, IEShims.dll is > missing, but also copying it from "Program files/Internet Explorer" did not > resolve the issue. Apparently some dll functions are missing. The ieshims.dll dependency is an optional one and most likely not the root cause for your issues. I've researched the issue about the missing sprintf_s symbol in msvcrt.dll and I have found the root cause of it. It's an issue in the mingw-w64 runtime (mingw-crt) where the secapi wrappers for various symbols aren't pulled in correctly. I'm about to fix this one and get the fix upstreamed > On Wine it does not work either, Qt5Gui crashes with the following output: > fixme:system:SetProcessDPIAware stub! > fixme:ole:RemUnknown_QueryInterface No interface for iid > {00000019-0000-0000-c000-000000000046} > fixme:d3d9:D3DPERF_GetStatus (void) : stub > wine: Unhandled page fault on read access to 0x00000004 at address 0x720cf0 > (thread 0009), starting debugger... > Unhandled exception: page fault on read access to 0x00000004 in 32-bit code > (0x00720cf0). > > It seems currently only OpenGL builds of mingw32-qt5 do work. Crashes in wine are harder to investigate as it's hard to tell whether wine itself triggers the crash or the application/library which is run inside of wine. The backtrace you mentioned only contains library names and no symbol names or line numbers, so in its current state it's impossible to tell what causes your crash in wine.
Patches proposed upstream @ http://sourceforge.net/p/mingw-w64/mailman/message/31863008/ Once upstream mingw-w64 accepts them, I'll backport them to F19/F20 and rebuild mingw-angleproject
Could you test if http://koji.fedoraproject.org/koji/buildinfo?buildID=493729 works better?
(In reply to Erik van Pienbroek from comment #9) > Could you test if > http://koji.fedoraproject.org/koji/buildinfo?buildID=493729 works better? Thank you for providing a fix to the errors. I installed mingw32-crt from [1] and mingw32-angleproject from [2] and rebuilt a sample app. On XP the vsprintf_s error is gone, however the app crashes though, as well as on Windows 7, see screenshots. Does Qt also have to be recompiled against mingw-crt? @Patrick Noffke: Do Qt5 (GUI) apps work for you on Windows 7 and with the fix on XP? How do you deploy the Qt dependencies? If it works for you, could you please provide a sample app and binaries? [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=493719 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=493729
Created attachment 855325 [details] Error running a Qt5 sample app on Windows 7
Created attachment 855336 [details] Error 1 running a Qt5 sample app on Windows XP
Created attachment 855337 [details] Error 2 running a Qt5 sample app on Windows XP
The error about the missing 'windows' plugin is very odd. Could you try to execute (profile) this program from inside the Dependency Walker? That way you should be able to find out why the 'windows' plugin couldn't be loaded. The other errors I can't explain at the moment. Are you able to use gdb (mingw32-gdb package) to catch a backtrace of this crash?
BTW, it shouldn't be necessary to update mingw32-crt (unless your own executable also uses vsprintf_s directly), but if you do you should also update mingw32-headers as well (the versions numbers of those two packages need to be as close to each other as possible)
@max: I managed to reproduce your crash here, it's an OpenGL specific issue in Qt5 so it's a different issue than the one initially mentioned here in this bug report by Patrick Noffke. Please file a separate bug report for your issue so we can continue there
@Erik van Pienbroek: It seems like you already backported the fix, as the vsprintf_s error is gone on XP, thank you for this. I'm glad someone can reproduce the crashes. I opened a new bug report for these, see [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1057983
PS: Sorry for this, the fix seems not to be backported yet, however the SVN builds of mingw-angleproject work fine.
The sprintf_s issue apparently is still there with the latest mingw-w64-crt (as was observed in bug 1057983). Therefore I just proposed another patch at mingw-w64 upstream to properly wrap that symbol in a secapi wrapper as well: http://sourceforge.net/p/mingw-w64/mailman/message/31887747/
Thank you for providing a fix, this works great and the missing dependency of sprintf_s is gone on Windows XP. Hope you can backport this soon.
The following happens on Arch Linux, will test it on Fedora soon: When compiling Angle against a r6469 build of crt-svn and headers-svn, the following errors appear during linking of libGLESv2: "/usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x2aa): undefined reference to `__stack_chk_guard' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x2c1): undefined reference to `__stack_chk_guard' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x553): undefined reference to `__stack_chk_fail' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-mingw_vfscanf.o):mingw_vfscanf.c:(.text+0x2fc): undefined reference to `__stack_chk_guard' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-mingw_vfscanf.o):mingw_vfscanf.c:(.text+0x60c): undefined reference to `__stack_chk_guard' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-mingw_vfscanf.o):mingw_vfscanf.c:(.text+0x2c31): undefined reference to `__stack_chk_fail' /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld: /usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-mingw_vfscanf.o): bad reloc address 0x14 in section `.rdata'" With a r6468 build of crt-svn and headers-svn, Angle compiles fine.
(In reply to max.mail from comment #21) > The following happens on Arch Linux, will test it on Fedora soon: > When compiling Angle against a r6469 build of crt-svn and headers-svn, the > following errors appear during linking of libGLESv2: > "/usr/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/ > libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x2aa): > undefined reference to `__stack_chk_guard' Please avoid cluttering bug reports with unrelated issues, especially when you're not the reporter of the bug. It makes it more harder to keep track of the progress of the original issue. The output you mentioned sounds like a toolchain issue on ArchLinux which I can't help you with.
mingw-winpthreads-3.1.0-1.fc20,mingw-w64-tools-3.1.0-1.fc20,mingw-headers-3.1.0-1.fc20,mingw-crt-3.1.0-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mingw-winpthreads-3.1.0-1.fc20,mingw-w64-tools-3.1.0-1.fc20,mingw-headers-3.1.0-1.fc20,mingw-crt-3.1.0-2.fc20
mingw-angleproject-0-0.9.svn2215.20130517.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mingw-angleproject-0-0.9.svn2215.20130517.fc20
Package mingw-winpthreads-3.1.0-1.fc20, mingw-w64-tools-3.1.0-1.fc20, mingw-headers-3.1.0-1.fc20, mingw-crt-3.1.0-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mingw-winpthreads-3.1.0-1.fc20 mingw-w64-tools-3.1.0-1.fc20 mingw-headers-3.1.0-1.fc20 mingw-crt-3.1.0-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2045/mingw-winpthreads-3.1.0-1.fc20,mingw-w64-tools-3.1.0-1.fc20,mingw-headers-3.1.0-1.fc20,mingw-crt-3.1.0-2.fc20 then log in and leave karma (feedback).
(In reply to Erik van Pienbroek from comment #22) > Please avoid cluttering bug reports with unrelated issues, especially when > you're not the reporter of the bug. It makes it more harder to keep track of > the progress of the original issue. The output you mentioned sounds like a > toolchain issue on ArchLinux which I can't help you with. I'm sorry for providing unnecessary information to this bug. The package updates stated above solve all Windows XP/sprintf_s related issues, and Qt5 OpenGL programs run fine on Windows XP (SP2, 32 bit) now. I left appropriate karma at the site linked above. Thank you very much for fixing this.
mingw-winpthreads-3.1.0-1.fc20, mingw-w64-tools-3.1.0-1.fc20, mingw-headers-3.1.0-1.fc20, mingw-crt-3.1.0-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mingw-angleproject-0-0.9.svn2215.20130517.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.