[next] Level corruption on some UDMF maps on aarch64 macOS

Sometimes (not every time) when a UDMF level loads, certain sectors may be drawn incorrectly and have no collision. Additionally, collision errors may appear in other parts of the map. This issue does not appear to affect non-UDMF levels. This also appears to happen on aarch64 Android, but I cannot confirm this. I will test on aarch64 Linux soon.

changed the description

On the exact same computer running Linux, and building with GCC, this issue does not happen. On macOS, I was building next with clang. Discussion in Discord confirms that, at least in some cases, affected Android builds also use clang. I will attempt to build SRB2 using clang on this machine to see what happens.

Okay, clang doesn't seem to be the ticket either. Building with clang 17.0.3 on Linux produced builds that work perfectly fine. How bizarre.

here is a video showing a possibly related bug on android as i couldn't get the visual bug (i do know that someone else did though), but the hole in the hub does do this

ok please upload this time

output.mp4

more instances can be found here

https://mb.srb2.org/threads/the-mobile-problem-except-its-by-me.40737/#post-631406

mentioned in issue #1198 (closed)

got it on x86 linux with CC="clang" make -j4 DEBUGMODE=1

mentioned in merge request !2438 (merged)

tested it out on RingRacers... robotink coaster errors out with this, ill get the log once im able to

then it sigsegvs with

master 8326292a
/home/bitten2up/RingRacers/src/acs/vm/ACSVM/ModuleACSE.cpp:615 (discriminator 1)
/home/bitten2up/RingRacers/src/acs/vm/ACSVM/ModuleACSE.cpp:562
??:0
/home/bitten2up/RingRacers/src/acs/vm/ACSVM/ModuleACS0.cpp:202
/home/bitten2up/RingRacers/thirdparty/fmt/include/fmt/format.h:3170
/home/bitten2up/RingRacers/thirdparty/fmt/include/fmt/format.h:3031 (discriminator 2)                     /home/bitten2up/RingRacers/thirdparty/fmt/include/fmt/format.h:2849                                       /home/bitten2up/RingRacers/src/k_hud.cpp:3982                                                             /home/bitten2up/RingRacers/src/k_hud.cpp:1355                                                             /home/bitten2up/RingRacers/src/fastcmp.h:30
/home/bitten2up/RingRacers/thirdparty/nlohmann-json/include/nlohmann/json.hpp:20140
/home/bitten2up/RingRacers/src/g_gamedata.h:143 (discriminator 3)
/home/bitten2up/RingRacers/thirdparty/nlohmann-json/include/nlohmann/json.hpp:11573 (discriminator 6)
/home/bitten2up/RingRacers/src/d_clisrv.c:2747
/home/bitten2up/RingRacers/src/command.h:187
/home/bitten2up/RingRacers/src/cvars.cpp:43
/home/bitten2up/RingRacers/src/cvars.cpp:143
/usr/include/c++/13.2.1/bits/stl_algobase.h:262
??:0                                                                                                      ??:0                                                                                                      /home/bitten2up/RingRacers/src/cvars.cpp:43

mentioned in commit 85376ebe

mentioned in merge request !2476 (merged)

closed

I didn't do that. Why did GitLab do that?

reopened

It's because I cherry-picked the fix to RR internal and Gitlab, for some godforsaken reason, decided to close it remotely.

However, it is fixed based on my testing, so this should be closed.

closed with merge request !2476 (merged)

mentioned in commit 4e9e321e