summaryrefslogtreecommitdiff
path: root/.github/workflows
diff options
context:
space:
mode:
authorNicky <nicky.dasmijn@posteo.nl>2024-04-10 21:02:40 +0200
committerAndrey Lihatskiy <alihatskiy@productengine.com>2024-04-12 15:17:02 +0300
commit7f021738ef2d74f78093dbe4fa37cbfa6645e05a (patch)
tree5d9d21e982aa55c857be5a20126df51fb51e53ab /.github/workflows
parent33c7b9701de1589e8e3875656a6bab4f8710e7a8 (diff)
Fix ASAN errors from LLVector4a::memcpyNonAliased16
Found by running with -fsanitze=thread Suggestion to avoid accessing invalid memory: In both cases memory will be allocated by can be accessed beyond bounds. In LLPolyMesh it can be off by at least one (+x%2). Though I am not even sure if even in best case it always will be a multiple of 16. In LLViewerJointMesh::updateFaceData the code tries to account for padding by, but the allocation in LLPolyMeshSharedData::allocateVertexData is done without any padding. Thus the sizes must not match. Replacing the calls with memcpy as a quick fix to see if the error goes away fixed address sanitzer complaining. It is up to debate if memcpy is a good replacement. LLVector4a::memcpyNonAliased16 was invented for performance. But on the other hand one could argue that nowadays every stdlib maintainer will very heavily optmize functions like memcpy themselves and could take advantage of CPU features the old LL implementation does not take into account. AVX comes to mind. In any case did I not measure any of this.
Diffstat (limited to '.github/workflows')
0 files changed, 0 insertions, 0 deletions