Odin
Odin copied to clipboard
Crash with constant procedure parameters
- Operating System & Odin Version: Windows x64,
odin.exe version dev-2022-02:093b2288
package test
import "core:fmt"
main :: proc() {
f :: proc($x: proc(int)) {
x(1)
}
f(proc(i: int) { fmt.println(i) })
}
Edit: Seems to occur due to the combination of $
, and passing a procedure-literal.
I could reproduce under OpenBSD with the following gdb backtrace:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000ab4d6f705dc in std::__1::__cxx_atomic_load<Ast*> (__a=0x58, __order=std::__1::memory_order_seq_cst) at /usr/include/c++/v1/atomic:1009
1009 return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
(gdb) bt
#0 0x00000ab4d6f705dc in std::__1::__cxx_atomic_load<Ast*> (__a=0x58, __order=std::__1::memory_order_seq_cst) at /usr/include/c++/v1/atomic:1009
#1 0x00000ab4d6f48098 in std::__1::__atomic_base<Ast*, false>::load (this=0x58, __m=std::__1::memory_order_seq_cst) at /usr/include/c++/v1/atomic:1625
#2 0x00000ab4d6e3d2e6 in check_get_params (ctx=0x7f7ffffdf4a8, scope=0xab7c7aab680, _params=0xab7ac287760, is_variadic_=0x7f7ffffdf497, variadic_index_=0x7f7ffffdf488, success_=0x7f7ffffdf487, specialization_count_=0x7f7ffffdf478, operands=0x7f7ffffdf9a0) at src/check_type.cpp:1637
#3 0x00000ab4d6de08e8 in check_procedure_type (ctx=0x7f7ffffdf820, type=0xab7c7aab730, proc_type_node=0xab7ac2877d0, operands=0x7f7ffffdf9a0) at src/check_type.cpp:1954
#4 0x00000ab4d6ddf967 in find_or_generate_polymorphic_procedure (old_c=0x7f7ffffe3058, base_entity=0xab7c7aaa9b0, type=0x0, param_operands=0x7f7ffffdfef0, poly_def_node=0xab7ac288370, poly_proc_data=0x7f7ffffdfde8) at src/check_expr.cpp:384
#5 0x00000ab4d6de11c6 in find_or_generate_polymorphic_procedure_from_parameters (c=0x7f7ffffe3058, base_entity=0xab7c7aaa9b0, operands=0x7f7ffffdfef0, poly_def_node=0xab7ac288370, poly_proc_data=0x7f7ffffdfde8) at src/check_expr.cpp:522
#6 0x00000ab4d6dfbf74 in check_call_arguments_internal (c=0x7f7ffffe3058, call=0xab7ac288370, proc_type=0xab7c7aaab30, entity=0xab7c7aaa9b0, operands=..., show_error_mode=CallArgumentMode_ShowErrors, data=0x7f7ffffe0fd8) at src/check_expr.cpp:4999
#7 0x00000ab4d6e01bc4 in check_call_arguments (c=0x7f7ffffe3058, operand=0x7f7ffffe27b0, proc_type=0xab7c7aaab30, call=0xab7ac288370, args=...) at src/check_expr.cpp:5939
#8 0x00000ab4d6e06a44 in check_call_expr (c=0x7f7ffffe3058, operand=0x7f7ffffe27b0, call=0xab7ac288370, proc=0xab7ac287c40, args=..., inlining=ProcInlining_none, type_hint=0x0) at src/check_expr.cpp:6488
#9 0x00000ab4d6e31288 in check_expr_base_internal (c=0x7f7ffffe3058, o=0x7f7ffffe27b0, node=0xab7ac288370, type_hint=0x0) at src/check_expr.cpp:9223
#10 0x00000ab4d6df7c0d in check_expr_base (c=0x7f7ffffe3058, o=0x7f7ffffe27b0, node=0xab7ac288370, type_hint=0x0) at src/check_expr.cpp:9341
#11 0x00000ab4d6e5028b in check_stmt_internal (ctx=0x7f7ffffe3058, node=0xab7ac288450, flags=32) at src/check_stmt.cpp:1393
#12 0x00000ab4d6e4ec42 in check_stmt (ctx=0x7f7ffffe3058, node=0xab7ac288450, flags=32) at src/check_stmt.cpp:504
#13 0x00000ab4d6e4d931 in check_stmt_list (ctx=0x7f7ffffe3058, stmts=..., flags=32) at src/check_stmt.cpp:102
#14 0x00000ab4d6e4d193 in check_proc_body (ctx_=0x7f7ffffe3268, token=..., decl=0xab76448ddc0, type=0xab764654e10, body=0xab7ac288490) at src/check_decl.cpp:1506
#15 0x00000ab4d6e64c0d in check_proc_info (c=0xab763f8dc80, pi=0xab764654f40, untyped=0x7f7ffffe34c0, procs_to_check_queue=0xab763f8e4b8) at src/checker.cpp:5099
#16 0x00000ab4d6e65556 in consume_proc_info_queue (c=0xab763f8dc80, pi=0xab764654f40, q=0xab763f8e4b8, untyped=0x7f7ffffe34c0) at src/checker.cpp:5214
#17 0x00000ab4d6e65fe9 in check_procedure_bodies (c=0xab763f8dc80) at src/checker.cpp:5262
#18 0x00000ab4d6e686af in check_parsed_files (c=0xab763f8dc80) at src/checker.cpp:5651
#19 0x00000ab4d6f260bd in main (arg_count=3, arg_ptr=0x7f7ffffe4478) at src/main.cpp:2622
(gdb) frame 2
#2 0x00000872219822e6 in check_get_params (ctx=0x7f7ffffd0658, scope=0x874993cf1b0, _params=0x8745f961760, is_variadic_=0x7f7ffffd0647, variadic_index_=0x7f7ffffd0638, success_=0x7f7ffffd0637, specialization_count_=0x7f7ffffd0628, operands=0x7f7ffffd0b50) at src/check_type.cpp:1637
1637 poly_const = exact_value_procedure(proc_entity->identifier.load() ? proc_entity->identifier.load() : op.expr);
(gdb) print proc_entity
$1 = (Entity *) 0x0
it failed in src/check_type.cpp:1637.
if (is_type_proc(op.type)) {
Entity *proc_entity = entity_from_expr(op.expr);
valid = proc_entity != nullptr;
poly_const = exact_value_procedure(proc_entity->identifier.load() ? proc_entity->identifier.load() : op.expr);
}
in gdb, proc_entity
is 0x0
, but it is deferenced with proc_entity->identifier.load()
.
just checking if valid
is true before evaluating seems to be enough to avoid the crash, but I am not knowing enough odin internal to be sure it is the right fix.
with it, building the test.odin snippet result in the following odin error:
/tmp/a/test.odin(10:7) Expected a constant value for this polymorphic name parameter
might be related #1578 :thinking: different scenario though
@Skytrias it could be related in the sens that both case are due to entity_from_expr()
returning nullptr
because the entity is Ast_ProcLit
.
Seems like inlining is the culprit.
crash:
foo :: proc($FN: proc()) {}
foo(proc(){}) //inline
successful compilation:
fn :: proc(){}
foo :: proc($FN: proc()) {}
foo(fn) //not inline anymore
Hello!
I am marking this issue as stale as it has not received any engagement from the community or maintainers 120 days. That does not imply that the issue has no merit! If you feel strongly about this issue
- open a PR referencing and resolving the issue;
- leave a comment on it and discuss ideas how you could contribute towards resolving it;
- leave a comment and describe in detail why this issue is critical for your use case;
- open a new issue with updated details and a plan on resolving the issue.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone..