MacOS Clang: Updating from 0.9.9.9 to latest causes memory corruption.

[SamCZ]

Hi, today I updated from 47585fd to latest and weird things started happening.

Rn I use glm for only projection, view, and simple vector math, nothing really special.

After the update my second engine viewport stopped working and while dragging imgui windows I get swapchain errors and also imgui draw errors.

Im not sure how this can happen, but after reverting back to the old commit, it started working like a charm.
I also tried disabling fast math, but it did nothing.

Im using C++20 Clang on Macbook pro M2 with Clion.

I will try to post more info when I investigate more, but I just wanted to show you guys this so we can quicky resolve it.

Edit: To get glm working on nevest I needed to set the cmake option for GLM_ENABLE_CXX_20 otherwise it would not compile because errors with c++98 compat.

[Tachi107]

Would you be able to use git bisect to find the first bad commit?

[SamCZ]

Would you be able to use git bisect to find the first bad commit?

Just yesterday in the night I found what was causing the crashes, its not because of glm, but even with that not crashing, my screen is blank. I will today do the bisect and let you know.

[SamCZ]

Sorry for still not replying, I could not yet do it. But I promise in few days I will do it. Meanwhile we have still the old commit.

[curldivergence]

Hi, I think I'm hitting the same (at least, similar) issue (macOS 14.5, M1, glm commit 33b0eb9fa336ffd8551024b1d2690e418014553b)

clang++ --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.5.0

The symptom is a segfault on innocent-looking code (foo and bar are local glm::vec3s)

uvec3 result = glm::uvec3{foo * bar};

I haven't gotten to the bottom of this yet, but my current understanding is that when glm::operator*<float, (glm::qualifier)0> calls glm::vec<3, float, (glm::qualifier)0>::vec, the calling convention is violated (x0 which should contain this actually contains 0x1, and then it is dereferenced below to store the result):

glm::vec<3, float, (glm::qualifier)0>::vec:
    0x100440bfc <+0>:  sub    sp, sp, #0x20
    0x100440c00 <+4>:  str    x0, [sp, #0x18]
    0x100440c04 <+8>:  str    s0, [sp, #0x14]
    0x100440c08 <+12>: str    s1, [sp, #0x10]
    0x100440c0c <+16>: str    s2, [sp, #0xc]
    0x100440c10 <+20>: ldr    x0, [sp, #0x18]
    0x100440c14 <+24>: ldr    s0, [sp, #0x14]
->  0x100440c18 <+28>: str    s0, [x0] # x0 = 0x0000000000000001 here
    0x100440c1c <+32>: ldr    s0, [sp, #0x10]
    0x100440c20 <+36>: str    s0, [x0, #0x4]
    0x100440c24 <+40>: ldr    s0, [sp, #0xc]
    0x100440c28 <+44>: str    s0, [x0, #0x8]
    0x100440c2c <+48>: add    sp, sp, #0x20
    0x100440c30 <+52>: ret

I'll think a bit more what the correct behavior should be in this case: right now I'm not sure if the output pointer should indeed be stored in x0 or in x8 since the latter register is used to return values that don't fit in x0/x1; anyway, as far as I can see, currently the stack address that looks like a valid place to output data is stored in both x1 and x8:

General Purpose Registers:
        x0 = 0x0000000000000001
        x1 = 0x000000017e99e514
        x2 = 0x00000000000120a8
        x3 = 0x000000012183b834
        x4 = 0x00001801000018c0
        x5 = 0x0000000000001800
        x6 = 0x000000000000000a
        x7 = 0x0000000000001700
        x8 = 0x000000017e99e514

I'll continue looking into this tomorrow, but if this rings any bells, please let me know :) Thanks!