GNOME Bugzilla – Bug 650833
Crash in COGL on Windows 32-bit (whenever Pango/text is used)
Last modified: 2011-11-25 15:58:43 UTC
Hi, I was trying to have Clutter/COGL build on Windows as I am working on Visual C++ support for these projects, which I managed to do. However, it seems that when I run any clutter sample applications that displays text in it under 32-bit mode, such as test-text-perf.c, test-text.c, test-random- text.c (under $(clutter_src_root)\tests\microbench), or the rotating crate example from http://wiki.clutter-project.org/wiki/Cogl/CoglBasicsExample, the program crashes on launch. The error code is c0000005, which means Access Violation (or segfault to *nix users). Interestingly, the program does not crash in programs which do not contain text in them, such as test-picking.c in microbench. Another interesting part is that when the same programs are run under x64 mode, these programs run alright without such crashes at all. I will attach the findings on the whereabouts of where the program crashed in the VS Debugger later, as I don't have access to it now. Thank you!
Sorry-I forgot to mention... The COGL used is from the version that has been decoupled from Clutter, with the recent changes from COGL and Clutter masters-and the situation did not occur in the earlier Clutter 1.6.14 release though, for your references.
Created attachment 189140 [details] The point where the test-text.exe crashed (Sorry for the delays for posting what I saw from the VS debugger) I have attached an image on where the VS debugger pointed out where the code had failed-where the yellow arrow is (at "static void _cogl_texture_2d_wrap_coords" in cogl/cogl-texture-2d.c [lines 64-85]). The debugger displayed "Run-Time Check Failure #2 - Stack around the variable 'int_part' was corrupted". This applied to all 32-bit programs that had text displayed in the graphical screen (but those without text was OK-such as test-picking), AFAICT--as mentioned, this interestingly did not occur on x64 builds. I will attach the call stack shortly. Thank you!
Created attachment 189141 [details] The call stack on the VS debugger The text file is the call stack I had from the debugger...
re-assigning to the newly created Cogl product.
Just a quick note on the software/hardware I used. This was occurring on my ASUS laptop and Apple Mac Mini (Late 2009). Hardware (Model/CPU/Graphics card)/OS: 1. ASUS F9J laptop/Intel Core2Duo T5600@1.83GHz/nVidia GeForce Go 7300/Windows XP Pro 32-bit 2. Apple Mac Mini (Late 2009)/Intel Core2Duo T7550@2.26GHz/nVidia 9400M/Windows 7 Ultimate 64-bit (native-BootCamp) Compilers used: Visual C++ 2008 Express (32-bit), Visual C++ 2010 Express (32-bit/x86-64). (Sorry, I was not able to reproduce this problem under MinGW builds as I could not manage to build COGL under MSYS) Steps to reproduce: (please note that all of my changes to Clutter and COGL regarding Visual C++ support is under the msvc-support branch under COGL and Clutter on git.gnome.org). -Run any 32-bit Clutter/COGL programs which displays text in the main window where the stage is drawn, such as test-text from tests\microbench. Expected outcome: displays window with "OH" and sizes in pixels in incremental sizes Observed outcome: Program crashes with debugger output as in "comment 3". Note that if program has no text in the stage, or if the program is compiled/run as x64, the program runs without a hitch. Thank you!
Sorry... But just wanted to make another update on my observations on this... I changed the title because when I ran the newly-included crate example, the program crashed (at the same spot, AFAICT, as the Debug binaries displayed "Run-Time Check Failure #2 - Stack around the variable 'int_part' was corrupted".) when compiled as 32-bit, but ran fine on x64... Please let me know if further info is needed. Thank you!
Created attachment 192157 [details] [review] Patch to fix crash on Windows during use of COGL-Pango (Bug 650833) Hi, It seems that there could be an overflow in int_part in cogl/cogl-texture-2d.c as float on 32-bit Windows could not hold the length of the values that are written into that variable in the _cogl_texture_2d_wrap_coords function-so this may be a potential problem on other 32-bit platforms too. I have attached a patch here from my msvc-support branch to declare int_part as double instead to work around this problem-though it may not be the best use of resources. This change ran fine on Windows x64 too-but sorry I do not have a 32-bit linux system to verify this though. p.s. By running the crate and hello example programs, it does seem to me that the aforementioned function is only called when COGL-Pango is used (or, at least when text is displayed in the COGL window/stage).
Thanks for looking into this. I think this may be a bug in the headers provided by MSVC. This has been reported here: http://connect.microsoft.com/VisualStudio/feedback/details/432366/modff-corrupts-stack We can't just change int_part to be a double because that would break any platforms not using these headers (ie, in that case it wouldn't write enough bits to fill the double). Are you able to upgrade your version of MSVC? Maybe we could just make Cogl require a recent enough version?
Hi Neil, Sorry, I should have mentioned this earlier--this occurs on Visual C++ 2008 and 2010, with the latest service packs for both-so there is no way to upgrade my compiler as they are the latest versions available already. So it seems that the problem mentioned in the MS Connect link is still there... Might need to make use of a workaround though then. Thanks for looking into this. God Bless.
Created attachment 192202 [details] [review] The workaround for modff on MSVC 32-bit Hi Neil, This is the workaround for modff that I propose for MSVC 32-bit environments. This will only be used by MSVC 32-bit builds, so other compilers/platforms are not affected Thank you! God Bless.
Thanks for the patch. However I don't think implementing our own version of modff is the right approach. modff has some fiddly semantics about preserving the sign of the return values even when it is zero (ie, it can return -0.0f) which your patch doesn't support. Maybe it would be better to make a wrapper that uses modf instead? I don't think the bug is limited to 32-bit environments. Doubles and floats are the same size across 32-bit and 64-bit platforms.
Created attachment 192234 [details] [review] Use a wrapper for modff when compiling with Visual Studio Visual Studio appears to have a broken macro implementation of modff in its headers. This patch adds a wrapper in cogl-util.h to make it use modf instead.
Hi Neil, Thanks for the patch--it did fix the issues-the patch also enabled the Clutter interactive tests to run on 32-bit builds successfully-previously some of those tests would crash, especially those that load images from files. The same applies for x64 builds. However, it does come to me that this modff bug of Visual C++ only affects 32-bit builds because the Clutter interactive tests that crashed on 32-bit builds (the ones I mentioned above) did not crash on 64-bit builds at all, without any workarounds for modff. So I think this workaround is needed only for 32-bit Visual C++ builds-but I think anyways that you would know the best way with this issue. p.s. As a side note, I also found that it is important to use the same CRT for all dependent DLLs of COGL (and Clutter), even down to ZLib and LibPNG to avoid crashes! Thank you! God Bless.
Created attachment 192351 [details] [review] Updated patch for wrapper for modff Hi Neil, I have updated your patch a little bit as the wrapper modff implementation is only needed on MSVC compiling COGL in 32-bit (x86) mode, as modff by itself works fine on MSVC compiling COGL in x64 mode, as I found by running the interactive tests of Clutter as I mentioned in my last comment. Please see which one suits better for general purposes-your original patch or the updated version included here. p.s. It also seems to me from your link (http://connect.microsoft.com/VisualStudio/feedback/details/432366/modff-corrupts-stack) that modff works fine on x64 and IA64. Thank you! God Bless.
Ah yes, I see what you mean. I looked in the header for VC++ and indeed it does have a separate #ifdef for 64-bit with a proper function declaration for modff. How bizarre! Sorry for the confusion.
Hi, I have incorporated the changes here in the msvc-support branch, so that hopefully this will bring MSVC compilation/usage support to COGL soon for public use and test (please see Bug 650020 in regards to the COGL/COGL-Pango MSVC support efforts). Thank you!
For reference notes: This would probably need to go in together with the patches for Bug 650020 as this seems to be affecting VS builds, which is under review there... Again, this fix is incorporated in the msvc-support branch of COGL now. Thanks, and God Bless.
I am closing this as modff is no longer used in COGL (please see bug 650020 comment 14). Thanks for the time involved God bless!