Tweak ASAN compile & fix a couple of bugs

[gajop]

No description provided.

[gajop]

There's also mikke89/RmlUi@master...gajop:RmlUi:fix-asan which is "unfortunately" in the RmlUI itself. Unfortunately because it doesn't seem like BAR has its own version of RmlUi, and I'd rather not put the (quite likely) higher effort it takes to merge upstream.

[sprunk]

Where did the 3rd element and its value come from?

[gajop]

It's a made up value, something that's valid but shouldn't take any effect when used with 2D textures.

I was thinking whether to express this as std::vector (heap allocation), zero initialized or setting a special enum value and a tiny branch check during use or just rewrite it as a struct that has a count member, and I ended up choosing this since it was simplest and I hoped comment explained it enough.

Happy to change to something else.

[sprunk]

Why not do it like this though? The previous initializer list had 2 elements and apparently it was fine.

- std::array<int32_t, 3>{ GL_REPEAT, GL_CLAMP_TO_EDGE, GL_REPEAT}
+ std::array<int32_t, 2>{ GL_REPEAT, GL_CLAMP_TO_EDGE}

If the 3rd is needed because something iterates it to 3 maybe that was the real problem rather than the container being an initializer list?

[lhog]

The array has to be of a fixed size, in this case of 3, just to cover a rare case of 3D textures.

[lhog]

Was std::optional<std::initializer_list<int32_t>> wrapModes flagged by ASAN?

[gajop]

yup, see c205c47

For each commit I included the original ASAN error message.
Apparently std::initializer_list should never be stored, as it doesn't copy anything (it's a view), so the original was just reference to something on the stack.

https://en.cppreference.com/w/cpp/utility/initializer_list.html

std::initializer_list may be implemented as a pair of pointers or pointer and length. Copying a std::initializer_list does not copy the backing array of the corresponding initializer list.

[loveridge]

The rmlui changes look good to me.

[lhog]

I cherry picked the first two so this will be mostly about Rml

[lhog]

@gajop can you PR mikke89/RmlUi@master...gajop:RmlUi:fix-asan ?

[gajop]

@gajop can you PR mikke89/RmlUi@master...gajop:RmlUi:fix-asan ?

Is it ok if I sit on this PR a while longer? I want to get to 0 crashes first and I might find a better way to do Rmlui. I dislike that I had to do a change in Rmlui itself, and maybe it's possible to avoid that.

Was a bit distracted with some data binding stuff... Will try to get back to this in the coming weeks..

[sprunk]

We've got open PRs from 2023 and nobody else seems to have ran into these issues so a bit of delay shouldn"t hurt.

[gajop]

Yeah fwiw I span regular BAR with Chobby for a couple of minutes of game time and nothing crashed. I didn't try BARs Rmlui version (there's a PR somewhere)

The crashes are Rmlui specific. There might be some leaks with the regular game but I didn't investigate deeply (that can have false positives / be too noisy, especially when it comes to end game cleanup)

[sprunk]

Tangential to this PR but perhaps the other sanitizer modes could be tried, apparently there's -fsanitize=undefined which sounds like it might be helpful vs desync.

[gajop]

Last I tried it on a diff project, undefined didn't produce any errors, false or true positive. So at least it shouldn't be a big time waster.

Thread sanitizer can also be useful, but it slows down the execution significantly and can have some false positives depending on the threading libraries used. It might just be too slow for Spring, idk.

Your best bet is the leak sanitizer that comes with ASAN. Slightly noisy, and only works on program exit, if both you and third party libraries clean up properly, but it can find memory leaks.

[gajop]

Oh and, past I checked they're mutually exclusive (except for Asan + lsan)