-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Regression in displaying of stacktraces with recursive functions. (on ARM?) #52334
Comments
I have the correct (full) error message for both cases on 1.8.5, 1.9.3, 1.10 and master so this is probably system specific. My system is
|
I guess so, too.
|
Adding to this, It would be nice if the Line 765 in ec32170
|
As pointed out in #52334, stack traces of `StackOverflowError`s currently don't highlight recursions enough. Spotting the light black `(repeats $n times)` note in a colorful stack trace is difficult. This PR highlights this note in bold warning color.
It works fine for me on Linux x86, i.e. it shows the "repeated" But on macOS with ARM cpu and Linux on a Raspberry (also with ARM CPU) the message is missing. This is using Julia 1.11.4 in both cases. |
This is already "broken" (?) in 1.8.5 on ARM macOS. As such I am not sure if it ever actually worked -- i.e. this may be less a regression and more "this feature is not supported on ARM / is only supported on x86" ? |
But in my post it seemed to work on 1.7 |
But was your post done in a ARM Linux binary? If so then necessarily for Linux as macOS ARM support was introduced in 1.8... |
Aha, that might be it then. |
Just tested on the Raspberry Pi (with 64 Linux) and the issue also occurs there. |
When getting stacktraces on non-X86 platforms, the first frame may not have been set up yet, incorrectly triggering this bad-frame detection logic. This should fix the issue of async unwind failing after only getting 2 frames, if the first frame happens to land in the function header. This is not normally an issue on X86 or non-signals, but also causes no expected issues to be the same logic there too. Fix #52334
When getting stacktraces on non-X86 platforms, the first frame may not have been set up yet, incorrectly triggering this bad-frame detection logic. This should fix the issue of async unwind failing after only getting 2 frames, if the first frame happens to land in the function header. This is not normally an issue on X86 or non-signals, but also causes no expected issues to be the same logic there too. Fix #52334 After (on arm64-apple-darwin24.3.0): ``` julia> f(1) Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable. ERROR: StackOverflowError: Stacktrace: [1] f(x::Int64) @ Main ./REPL[3]:1 [2] g(x::Int64) @ Main ./REPL[4]:1 --- the above 2 lines are repeated 39990 more times --- [79983] f(x::Int64) @ Main ./REPL[3]:1 ``` n.b. This will not fix and is not related to any issues where profiling gets only a single stack frame during profiling of syscalls on Apple AArch64. This fix is specific to the bug where it gets exactly 2 frames.
When getting stacktraces on non-X86 platforms, the first frame may not have been set up yet, incorrectly triggering this bad-frame detection logic. This should fix the issue of async unwind failing after only getting 2 frames, if the first frame happens to land in the function header. This is not normally an issue on X86 or non-signals, but also causes no expected issues to be the same logic there too. Fix #52334 After (on arm64-apple-darwin24.3.0): ``` julia> f(1) Warning: detected a stack overflow; program state may be corrupted, so further execution might be unreliable. ERROR: StackOverflowError: Stacktrace: [1] f(x::Int64) @ Main ./REPL[3]:1 [2] g(x::Int64) @ Main ./REPL[4]:1 --- the above 2 lines are repeated 39990 more times --- [79983] f(x::Int64) @ Main ./REPL[3]:1 ``` n.b. This will not fix and is not related to any issues where profiling gets only a single stack frame during profiling of syscalls on Apple AArch64. This fix is specific to the bug where it gets exactly 2 frames. (cherry picked from commit f82917a)
It seems a lot of the niceness that has been added for "stackoverflow type" of errors (or just generally when a function is called recursively) has been lost:
As an example:
1.7:
1.8+:
The
part is lost.
Another example:
1.7:
1.8:
1.8 says
repeats 2 times
which seems wrong..The text was updated successfully, but these errors were encountered: