00:10 fdobridge: <g​fxstrand> I think I'm going to have to admit defeat on this weird clear issue for today and go eat some suppe.r
00:10 fdobridge: <g​fxstrand> I think I'm going to have to admit defeat on this weird clear issue for today and go eat some supper. (edited)
00:29 fdobridge: <z​mike> post supper pics
02:42 fdobridge: <g​fxstrand> Supper tonight was pea soup. It tastes great but doesn't make for the most interesting pics, in afraid.
02:42 fdobridge: <g​fxstrand> Also, I didn't take any. 😝
02:44 fdobridge: <z​mike> smh we all know you just ate triangles again
03:21 fdobridge: <g​fxstrand> No, I had saltine crackers with my soup. Those are definitely quads.
18:53 KungFuJesus: so, the 16 byte alignment require of gc_slab is made by the alignas bit happening at the beginning of the struct
18:54 KungFuJesus: there's also a comment in the ralloc_size function that computes the allocation + padding that not all platforms have 16 byte alignment out of malloc (I suspect this is definitely true for powerpc64)
18:56 KungFuJesus: This bug might _actually_ be some silliness with alignment and induced alignment requirements made for the struct
19:00 KungFuJesus: I half wonder if this behavior never shows up in x86 land because glibc's been returning 16 byte mallocs for a while on x86
19:14 KungFuJesus: So this is a bit odd, ralloc_size appears to have tried to do the calculation to figure out how many bytes to overallocate but then dererferences things at the beginning of the allocation. Since C11 none of this has been all that necessary (though, Microsoft's C libraries might be the dumb exception to this)
19:24 KungFuJesus: another interesting source of fun is that the corrupted compiled shaders get written into the shader cache it would seem
19:47 KungFuJesus: One other interesting part in that area of code is the usage of canaries when compiled with NDEBUG. That's another potential delta that maybe affects things that I might want to explore disabling to see if the problem goes away. It also just could be that the compiler is emitting a direct read from heap when compiled with optimizations and is otherwise doing a temporary read from the stack for
19:47 KungFuJesus: strict correctness with alignment
22:35 KungFuJesus: anholt: Yeah, something tells me I've been barking up the wrong tree the entire time hunting this bug. I did find a great deal of UB but I think it's not what's causing the harm. I think I need to use msan. I'm seeing the same issues about incorrect vptr's when using llvmpipe and yet it works every time. The issue I'm hunting is hiding in nv30's fragment shader compilation, somewhere
22:36 KungFuJesus: msan I know for a fact poisons and tracks indirect memory usage, as well as their allocations (I think on both stack and heap). Maybe then I can find where the memory for this isn't being initialized
22:38 KungFuJesus: The alignment issue it's complaining about is definitely resolved by letting it assume 8 byte alignment is the best like it is on 32 bit platforms. Even using aligned alloc with 16 byte alignment trips that UB, which means that realloc is likely returning back 8 byte aligned memory. This is probably some artifact from how glibc has been compiled, but very unlikely the source of the issue