[cairo] pixman TLS crash on win32 under java-vm

[Thorgrimsson, Chris]

Hi Mikhail,

I too ran into the same issue using the VisualWorks Smalltalk vm on win32. I hadn't yet found your post so I built pixman with the PIXMAN_NO_TLS preprocessor to get past my failure. That also worked. However, I would like to have TLS support. Is there any chance you can share the modifications you made to the MINGW macros? Perhaps with your changes, the pixman folks can make this a permanent addition to pixman-compiler.h for the win32 people using pixman?

Thanks,
-Chris

From: cairo-bounces+chris.thorgrimsson=lamrc.com at cairographics.org [mailto:cairo-bounces+chris.thorgrimsson=lamrc.com at cairographics.org] On Behalf Of Kozhevnikov Mikhail
Sent: Wednesday, September 01, 2010 6:28 PM
To: cairo at cairographics.org
Subject: Re: [cairo] pixman TLS crash on win32 under java-vm

Hi,

Apparently the reason is that, according to MSDN<http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx>, On Windows operating systems before Windows Vista, __declspec( thread ) has some limitations. If a DLL declares any data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, you cannot extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.

Thus the problem isn't confined to our application. A reasonable solution would be to use the TlsAlloc et al. In fact, the MINGW version of pixman TLS macros seems to do the trick with little modifications.

Cheers,
Mikhail.

01.09.2010, 20:52, "Kozhevnikov Mikhail" :
> Hi,
>
> I've got a rather strange setup here, which causes pixman to crash. It seems to happen in line 657 of pixman.c that reads
>
> cache = PIXMAN_GET_THREAD_LOCAL (fast_path_cache);
>
> which disassembles into
>
> 102F8922 mov edx,dword ptr [__tls_index (1064AEDCh)]
> 102F8928 mov eax,dword ptr fs:[0000002Ch]
> 102F892E mov ecx,dword ptr [eax+edx*4]
> 102F8931 add ecx,108h
> 102F8937 mov dword ptr [cache],ecx
>
> where the third instruction is the one to cause the crash.
>
> The call sequence is as follows:
> do_composite
> pixman_image_composite32
> pixman_image_composite
> _cairo_image_surface_composite
> _cairo_surface_composite
> _cairo_win32_scaled_font_show_glyphs
> _cairo_scaled_font_show_glyphs
> _cairo_surface_old_show_glyphs_draw_func
> _clip_and_composite
> _cairo_surface_fallback_show_glyphs
> _cairo_surface_show_text_glyphs
> _cairo_gstate_show_text_glyphs
> cairo_show_text
>
> The 32-bit binaries are built from the latest cairo/pixman release sources with VS 9.0 under Win Server 2008 x64 and are linked into a dll that's loaded by the Java VM on a Win XP x86 machine. An interesting point is that we've failed to reproduce this error on 32-bit Vista or on the same machine, but calldoing the same stuff from a C++ application without using Java.
> I suspect that this has something to do with the TLS machinery in use. Has anyone ran across this?
> Is there a way to prevent pixman from using TLS?
>
> Cheers,
> Mikhail.
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20101130/6c9bb634/attachment.htm>