[18.1.5->18.1.6 regression] clang segfaults when building llvm itself on ppc64/ppc64le on chimera linux (PPCMergeStringPool) #92991
Labels
Milestone
Comments
github-actions
bot
added
the
clang
EugeneZelenko
added
backend:PowerPC
crash
|
@llvm/issue-subscribers-backend-powerpc Author: alice (nekopsykose)
probably caused by https://github.com//pull/91557
on ppc64le: on ppc64: 18.1.5 was fine, so given the error i assume it was that PPCMergeStringPool change specifically (no manual bisect). backtrace on ppc64le: https://img.ayaya.dev/T096XJsi3Clz (issue body limit) (i don't have one for ppc64), rerunning it manually seems to have failed on exegesis instead of flang too: cc @nikic |
|
I see what the problem is. I'll see if it's possible to construct a test case. |
nikic
added a commit
to nikic/llvm-project
that referenced
this issue
May 22, 2024
In llvm#88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. I think the case where this happens is constant users where the replacement might result in the destruction of the original constant. I wasn't able to come up with a test case though. This is intended to fix llvm#92991.
|
Candidate fix at #92996. I'm reasonably sure that this is the problem, but I didn't manage to come up with a test case. If you could dump the bitcode so I can reduce it that would be great. |
|
@tstellar This issue may warrant another point release. |
|
what would you like the bitcode of? X86TargetMachine.cpp.o? what command should i use (llvm-dis)? i could also upload the whole object somewhere |
|
@nekopsykose The fact that this is a ThinLTO build makes it a bit tricky. I think the best way is to pass |
|
sorry, that took forever. the builds take a while and this actually.. does not trigger every time :) here is the .bc (was named ran through llvm-dis for .ll https://img.ayaya.dev/pNwwzqUBr2lq (but i think you know the rest) hopefully that is helpful; i still have all the temps laying around |
|
@nekopsykose Thanks! I've reduced this to the following test case, which produces a use-after-free error under address sanitizer: target triple = "powerpc64le-unknown-linux-gnu"
@g = private constant [4 x i32] [i32 122, i32 67, i32 35, i32 56]
@g2 = private constant [1 x i64] [i64 1], align 8
define void @test(ptr %p, ptr %p2) {
store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 1), ptr %p
store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 2), ptr %p2
ret void
}This is very similar to how originally tried to reproduce this, but it turns out that the used GEP type is important here -- we don't get the use-after free with i8 GEPs for whatever reason. |
nikic
added a commit
to nikic/llvm-project
that referenced
this issue
May 23, 2024
In llvm#88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. I think the case where this happens is constant users where the replacement might result in the destruction of the original constant. I wasn't able to come up with a test case though. This is intended to fix llvm#92991.
nikic
added a commit
that referenced
this issue
May 27, 2024
In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes #92991.
|
/cherry-pick 9f85bc8 |
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
May 27, 2024
In llvm#88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm#92991. (cherry picked from commit 9f85bc8)
|
/pull-request #93442 |
freebsd-git
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
May 30, 2024
[PPCMergeStringPool] Only replace constant once (#92996) In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm/llvm-project#92991. This fixes a possible crash when building crypto/openssh/sshkey.c for PowerPC targets. Reported by: cperciva PR: 276104 MFC after: 3 days
freebsd-git
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
Jun 2, 2024
[PPCMergeStringPool] Only replace constant once (#92996) In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm/llvm-project#92991. This fixes a possible crash when building crypto/openssh/sshkey.c for PowerPC targets. Reported by: cperciva PR: 276104 MFC after: 3 days (cherry picked from commit f30188c)
freebsd-git
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
Jun 2, 2024
[PPCMergeStringPool] Only replace constant once (#92996) In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm/llvm-project#92991. This fixes a possible crash when building crypto/openssh/sshkey.c for PowerPC targets. Reported by: cperciva PR: 276104 MFC after: 3 days (cherry picked from commit f30188c)
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Jun 4, 2024
In llvm#88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm#92991. (cherry picked from commit 9f85bc8)
bsdjhb
pushed a commit
to bsdjhb/cheribsd
that referenced
this issue
Sep 3, 2024
[PPCMergeStringPool] Only replace constant once (#92996) In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes llvm/llvm-project#92991. This fixes a possible crash when building crypto/openssh/sshkey.c for PowerPC targets. Reported by: cperciva PR: 276104 MFC after: 3 days
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
probably caused by #91557
on ppc64le:
on ppc64:
18.1.5 was fine, so given the error i assume it was that PPCMergeStringPool change specifically (no manual bisect).
backtrace on ppc64le: https://img.ayaya.dev/T096XJsi3Clz (issue body limit) (i don't have one for ppc64), rerunning it manually seems to have failed on exegesis instead of flang too:
cc @nikic
The text was updated successfully, but these errors were encountered: