Hi, I compiled a static build of cairo on Windows with MSVC9. I'm using only the svg surface. If the the cairo_create call fails (because I set an invalid filename) _cairo_set_error is called which results in an access violation in the _cairo_atomic_int_cmpxchg function. The reason is that _cairo_atomic_mutex hasn't been initialized at that point. If I call CAIRO_MUTEX_INIT(_cairo_atomic_mutex) or CAIRO_MUTEX_INITIALIZE() before that point everything works as expected.
Gillen, thanks for the report. I will try to remember to look over which pathways are missing the INITIALIZER. However, do you mind investing why you need the atomic mutex in the first place? i.e. how we are not detecting or have chosen the correct atomics ops for windows. [There is a massive performance cost in using the mutex based fallbacks instead of atomic ops.]
Well I build cairo with my own build system, so I could have missed an important configuration step. But if I understand the code correctly there are only 2 implementations of atomic ops: The Intel atomic ops which don't work with the Microsoft compiler and the atomic_ops library which I currently don't have installed. Is there another one which I am missing?
Oh well. I have memories of at least the Intel mmx/sse[123] intrinics being available for MSVC, or at least something approaching interoperability. For someone knowledgeable in the Win32 APIs I am sure that adding the equivalent wouldn't be too challenging. InterleavedLockExchange() and friends, IIRC.
Created attachment 34513 [details] [review] Win32 atomic ops Well here is a patch that implements the needed defines with winapi functions. It works for my very simple usecase, but I haven't tested it further. If you want to use atomic ops, cairo also needs the ffs function which doesn't exist in MSVC. The following code can replace it: int ffs(int mask) { unsigned long index; if (_BitScanForward(&index, mask) == 0) return 0; else return index + 1; }
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/245.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.