Closed MortimerSnerd closed 1 year ago
Fixed here: https://github.com/aardappel/lobster/commit/128669227075a596dd463ddfc11fccca7d5b6bb6
The cause was that it didn't generate a vtable entry for extruded_sphere since the code never constructs one, so it then concludes it 0 vtable entry is ok, but then the backend hits the assert or generates a reference to a fun_0 that doesn't exist. So instead now this case is handled, and it put a ref to a function that just aborts in the vtable. This should make it more resilient against future such cases, but if there's ever a missing vtable entry for the wrong reasons we'll get that abort instead :)
Interesting. In the code the reproduction was cut from, extruded_sphere is constructed. But the fix you committed does work, and I tested to make sure all collision_shape types were instantiated and called, and no aborts.
Thanks!
Ah cool, so maybe the assert you got had a slightly different cause, but the fix appears to apply to both. Like I said this is more robust, and no idea why I didn't do it this way originally.
Updated to commit 192e95e5c942087338da30f273b9930ae5ae6641
After updating, started to get JIT failures. Running with the debug version of lobster netted me this assertion:
Assertion failed: de.sf->subbytecodestart, file C:\src\lobster\dev\src\lobster\codegen.h, line 311
Seems to be happening with a virtual move_to method that's used in a small class hierarchy.
To reproduce, here is chopped down example. This is main.lobster:
And here is gphysics, that has the class hierarchy:
Let me know if you need anything else.