It is possible that you may sometimes get crashes or wrong results. Follow these topics

Memory Allocation:

Recall that cglm does not alloc any memory on the heap. cglm functions work like memcpy; they copy data from src, make calculations, then copy the result to dest.

You are responsible for allocation of src and dest parameters.


vec4 and mat4 types require 16 byte alignment. These types are marked with the align attribute to let the compiler know about this requirement.

Since MSVC (Windows) throws this error:

“formal parameter with requested alignment of 16 won’t be aligned”

The alignment attribute has been commented out for MSVC

#if defined(_MSC_VER)
#  define CGLM_ALIGN(X) /* __declspec(align(X)) */
#  define CGLM_ALIGN(X) __attribute((aligned(X)))

So MSVC may not know about alignment requirements when creating variables. The interesting thing is that, if I remember correctly, Visual Studio 2017 doesn’t throw the above error. So we may uncomment that line for Visual Studio 2017, you may do it yourself.

This MSVC issue is still in TODOs.

UPDATE: Starting with v0.4.5, cglm provides an option to disable the alignment requirement. Also, alignment is disabled for older msvc versions by default. Now alignment is only required in Visual Studio 2017 version 15.6+ if the CGLM_ALL_UNALIGNED macro is not defined.

Crashes, Invalid Memory Access:

Most likely, you are trying to write to an invalid memory location.

You may have used a wrong function for what you want to do.

For example, you may have called a glm_vec4_ function for a vec3 data type. It will try to write 32 bytes, but since vec3 is 24 bytes, it should throw a memory access error or exit the app without saying anything.


On MSVC or some other compilers, if alignment is enabled (default) then double check alignment requirements if you got a crash.
If you send GLM_VEC4_ONE or similar macros directly to a function, it may crash.
Because the compiler may not apply alignment as defined on typedef to that macro while passing it (on stack) to a function.

Wrong Results:

Again, you may have used a wrong function.

For instance if you use glm_normalize() or glm_vec3_normalize() for a vec4, it will assume that the passed param is a vec3, and will normalize it for vec3. Since you need a vec4 to be normalized in your case, you will get wrong results.

Accessing a vec4 type with vec3 functions is valid, you will not get any error, exception or crash. You only get wrong results if you don’t know what you are doing!

So be careful, when your IDE (Xcode, Visual Studio …) tries to autocomplete function names, READ IT :)

Also implementation may be wrong, please let us know by creating an issue on Github.

BAD_ACCESS : Thread 1: EXC_BAD_ACCESS (code=EXC_I386_GPFLT) or Similar Errors/Crashes

This is a similar issue with alignment. For instance if you compiled cglm with AVX (-mavx, intentionally or not) and if you use cglm in an environment that doesn’t support AVX (or if AVX is disabled intentionally) e.g. environment that max support SSE2/3/4, then you probably get BAD ACCESS or similar…

Because if you compile cglm with AVX it aligns mat4 with 32 byte boundary, and your project aligns that as a 16 byte boundary…

Check alignment, supported vector extension, or simd in cglm and linked projects…

Other Issues?

Please let us know by creating an issue on Github.