You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following DaphneDSL script crashes with a segfault:
test.daphne:
# Update a matrix inside then-branch of if-statement with value computed outside if-statement# (scf.if gets rewritten to arith.select).X= [0];
Y=X+1;
# r must be unknown at compile-time (otherwise, the entire "if" gets optimized away)r=as.scalar(rand(1, 1, 0, 1, 1, -1));
if(r)
X=Y;
print(X);
output of bin/daphne test.daphne:
bin/daphne(+0x172dea2)[0x5a36c5d44ea2]
/lib/x86_64-linux-gnu/libc.so.6(+0x43090)[0x7774f506f090]
[error]: Got an abort signal from the execution engine. Most likely an exception in a shared library. Check logs!
Execution error: Returning from signal 11
The reason becomes clear when looking at the IR after managing object reference counters:
output of bin/daphne --explain obj_ref_mgnt test.daphne:
The reference counters of both inputs to arith.select (%15, %14) are decreased right after that operation. However, the result (%20) is one of them at run-time. Thus, a double-free happens when decRef is applied to %20 later.
The text was updated successfully, but these errors were encountered:
- The MLIR operation arith.select is frequently created during the canonicalization of scf.if (which, in turn, is created by DaphneDSL if-statements).
- arith.select takes a boolean argument (condition) plus two additional arguments, one of which it selects/returns based on the value of the condition.
- arith.select needs to be taken into account in DAPHNE's object reference counter management, because:
- We decrease the reference counter of SSA values after their last use as operands (the arith.select could be the last user).
- We have no clue which of the two last operands of arith.select is returned at run-time.
- However, the return value is the same runtime object as one of the two latter operands.
- To ensure the correct reference counter for the result after the arith.select, we need to increase the counter of the result before we decrease the counters of the operands.
- We had already implemented this fix, but applied it only for string operands/results.
- However, we must apply the fix for all operand/result types that have a reference counter at run-time.
- Fixed ManageObjRefPass.
- Added several script-level test cases testing the behavior for matrices, frames, lists, and strings and different settings of the if-then-else in DaphneDSL.
The following DaphneDSL script crashes with a segfault:
test.daphne
:output of
bin/daphne test.daphne
:The reason becomes clear when looking at the IR after managing object reference counters:
output of
bin/daphne --explain obj_ref_mgnt test.daphne
:The reference counters of both inputs to
arith.select
(%15
,%14
) are decreased right after that operation. However, the result (%20
) is one of them at run-time. Thus, a double-free happens whendecRef
is applied to%20
later.The text was updated successfully, but these errors were encountered: