-
-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfault in 'Simplify the CFG' pass when discarding a capture in a match inside a loop #2767
Comments
This goes back to the introduction of This actor Main
new create(env: Env) =>
let x: (None | U8) = 1
while true do
let y: None = match x
| let z: U8 => None
end
end compiles. So this is related to I haven't determined exactly the commit when this happened. It might have always happened. I gave up eventually. |
I tried to figure out when this was introduced. It was in #1499 when this syntax was first allowed. Prior to that commit, the syntax wasn't allowed. Also, the following compiles successfully: actor Main
new create(env: Env) =>
let x: (None | U8) = 1
while true do
let y: None = match x
| let _: U8 => None
end
end However, when compiled without The following also results in the segfault ( actor Main
new create(env: Env) =>
let x: (None | U8) = 1
while true do
let _: None = match x
| let y: U8 => None
end
end Same segfault for this: actor Main
new create(env: Env) =>
while true do
let _: None = None
end However, the following compiles but has the same actor Main
new create(env: Env) =>
while true do
let _: None = None
let y: None = None
end The following also has the same segfault as the original report: actor Main
new create(env: Env) =>
var y: Bool = true
while y do
let _: None = None
end However, the following compiles and runs successfully: actor Main
new create(env: Env) =>
var y: Bool = true
while y do
let _: None = None
y = false
end My guess is that this is related to optimizations that try and remove the while loop altogether because it is an infinite loop with no exit condition. |
Just a note: such an "optimization" would violate the semantics of a program. It is safe to remove code after the infinite loop (with a warning, of course), because it's unreachable, but not the loop itself. |
@burjui can you clarify what you mean by "remove the code after the infinite loop"? |
This is a bug somewhere in |
Looks like there's also a type checking bug involved in this. |
@SeanTAllen I mean that if there is some code after an infinite loop, it can be considered unreachable and safe to remove. |
I'm no longer able to reproduce this bug. |
This causes a segfault on Arch Linux x86_64 with Pony 0.22.6 and on issue-2760 branch:
GDB stacktrace:
The text was updated successfully, but these errors were encountered: