Move to fat pointers to remove UB#2382
Conversation
|
Is there any way to keep the vtable inside |
|
It doesn't work for |
|
Oh, true... hmm |
|
Would it be possible to only make PyObjectWeak a fat pointer? Store it in |
|
The other problem is that I get stack overflows again :(, gonna see what is causing those. Making PyObjectWeak a fat pointer might fix that. |
|
I might also look into unifying the vtable and PyTypeRef, since CPython has the tp_dealloc slot and all, I just have to figure out how to make that safe still to create types |
|
Hmmm more stack overflows. I put it in LLDB and it keeps calling the same destructor over and over... Weird. |
|
Do you remember what the WASM bug was last time? |
|
It looks like you figured it out, but I had made layout assumptions that didn't hold up on wasm, specifically wrt |
|
This appears to fix #2381 FYI, if you want to add edit: I guess it would be more accurate to say that "instead of immediately exiting and complaining at me, miri instead slowly heats up my CPU for >15 minutes while it chews through my entire 32gb of RAM". Miri is slow AF. I guess it's still a good sign. |
|
@coolreader18 @carbotaniuman how is this ended up? |
|
Now that the structure of |
|
FYI I'm finally working on a big overhaul to PyObjectRef's implementation/our object model that'll fix the UB: |
closes #2381