<div>Hi,</div><div> </div><div>Apparently the reason is that, according to <a href="http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx">MSDN</a>,<em> 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.</em></div><div> </div><div>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.</div><div> </div><div>Cheers,</div><div>Mikhail.</div><div> </div><div>01.09.2010, 20:52, "Kozhevnikov Mikhail" :</div><div>> Hi,</div><div>></div><div>> 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</div><div>></div><div>> cache = PIXMAN_GET_THREAD_LOCAL (fast_path_cache);</div><div>></div><div>> which disassembles into</div><div>></div><div>> 102F8922 mov edx,dword ptr [__tls_index (1064AEDCh)]</div><div>> 102F8928 mov eax,dword ptr fs:[0000002Ch]</div><div>> 102F892E mov ecx,dword ptr [eax+edx*4]</div><div>> 102F8931 add ecx,108h</div><div>> 102F8937 mov dword ptr [cache],ecx</div><div>></div><div>> where the third instruction is the one to cause the crash.</div><div>></div><div>> The call sequence is as follows:</div><div>> do_composite</div><div>> pixman_image_composite32</div><div>> pixman_image_composite</div><div>> _cairo_image_surface_composite</div><div>> _cairo_surface_composite</div><div>> _cairo_win32_scaled_font_show_glyphs</div><div>> _cairo_scaled_font_show_glyphs</div><div>> _cairo_surface_old_show_glyphs_draw_func</div><div>> _clip_and_composite</div><div>> _cairo_surface_fallback_show_glyphs</div><div>> _cairo_surface_show_text_glyphs</div><div>> _cairo_gstate_show_text_glyphs</div><div>> cairo_show_text</div><div>></div><div>> 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.</div><div>> I suspect that this has something to do with the TLS machinery in use. Has anyone ran across this?</div><div>> Is there a way to prevent pixman from using TLS?</div><div>></div><div>> Cheers,</div><div>> Mikhail.</div><div>> --</div><div>> cairo mailing list</div><div>> cairo@cairographics.org</div><div>> http://lists.cairographics.org/mailman/listinfo/cairo</div>