Fix bugs in arithm_op() for InputArray (src == dst) case. #13570
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix bugs in
arithm_op()
forInputArray
(src == dst)
case.It is a well-known issue that
InputArray
(src == dst)
can cause problems in opencv.So I try to fix this issue through this PR.
The cause of this problem is the recreate of
dst
by callcreate()
.There are many ways to solve this problem, but most of them are difficult solutions.
Store Mat itself inside
Input/OutputArray
, not the pointer to it, but it would noticeably increase the overhead and also It is possible to generate a side effect bug on any code that usesInputArray
.So it is difficult to solve the problem for every part that can be
(src == dst)
by modifying InputArrayIn most cases, we can prevent the
(src == dst)
case withCV_Assert(src1.getObj() != dst.getObj())
However, in the case of
Mat
's+=
operations, we must allowsrc == dst
.Change the internal state of
InputArray
to solve this problem is difficult and dangerous.So I propose to make a temporary
Mat
forsrc
on the stack whensrc == dst
at the beginning of thearithm_op
function.I think this method can avoid this problem with small overhead and the possibility of side effects being small.
The reasons are as follows.
Anyway, in the
arithm_op
function,src
will be converted viagetMat()
orgetUMat()
to be used inside the operation function.Therefore, if we create a temporary
Mat
(orUMat
) forsrc
at the beginning of the function, the overhead would be small.If
src
isMat
(orUMat
), it is only a ref count increment and more use of stack memoryOtherwise It may take time to convert to
Mat
, but in the case ofarithm_op
function it must be converted byGetMat()
(orGetUMat()
) function to be used inside this function anyway.So this is not an additional overhead.
After the above operation, even if
dst
is recreated in the case ofsrc == dst
,psrc
is safe because it refers to the temporaryMat
.This temporary
Mat
is created on the stack and will disappear when the function ends.The following issues can be solved with this modification.
issue #9688
issue #8385
I want to solve this problem.
Please let me know if this PR has a problem or if there are other good solutions