-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
eval and execute at toplevel is (still) invalid #51267
Comments
Reduced: struct Tokenizer
end
Base.IteratorSize(::Type{Tokenizer}) = Base.SizeUnknown()
function make_tokenizer()
quote
Base.iterate(::Tokenizer, state=0) = nothing
end
end
for x in 1
eval(make_tokenizer())
collect(Tokenizer())
end Reproduces all the way back to 1.0. |
No, that is just the well-known issue that you are not permitted to both eval and execute code in a loop at top-level |
Seems not so well-known.. what is the cause/rationale? |
I've been watching the issue tracker for like two years and wrttiten Julia code daily for five years, so it can't be that well known. |
Running |
It's not the collect - see the reduced MWE at the top of OP which is your example, but a bit further reduced |
Well, it is the |
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> (cherry picked from commit d51ad06)
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> (cherry picked from commit d51ad06)
I think I would normally expect a world age error here, no? |
Correct. But codegen intentionally skips emitting that error, which can sometimes lead to crashes like this |
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> (cherry picked from commit d51ad06)
This problem happens on Julia 1.6.7, 1.7.3, 1.8.5, 1.9.3, 1.10-beta2 and master. It might possibly also happens on older versions, but Automa.jl only supports Julia 1.6 and above.
MWE:
Reduced to this snippet with the help of @maleadt
Old way of of reproducing
Make a test file
/tmp/foo.jl
with the following contentNow, in a project with Automa master branch, #733b8cf (or the released v1.0.0)
Interestingly, if, instead of generating the code during the session, we instead manually write out the code like this, it does not crash:
Also, including the file after manually running
make_tokenizer
doesn't crash either:...which suggests to me that the bug could have something to do with the Julia interpreter, which runs the top-level for loop in
foo.jl
Crash message:
The text was updated successfully, but these errors were encountered: