| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899 |
- .. default-domain:: C
- Troubleshooting
- ================================================================================
- 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.
- Alignment:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- **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
- .. code-block:: c
- #if defined(_MSC_VER)
- # define CGLM_ALIGN(X) /* __declspec(align(X)) */
- #else
- # define CGLM_ALIGN(X) __attribute((aligned(X)))
- #endif.
- 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.
- **UPDATE - IMPORTANT:**
- | 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.**
|