Closed gergondet-woven closed 3 months ago
Hi @gergondet-woven,
thanks for your interest in Proxsuite and for raising this issue with a detailed analysis. You are right, there is indeed a mismatch. I discussed it with @Bambade and you can fix it by changing the dimension passed to head
to match new_cols
(by using qpwork.n_c
instead of qpmodel.dim
).
qpwork.ldl.rank_r_update(
- new_cols, qpwork.dw_aug.head(qpmodel.dim), stack);
+ new_cols, qpwork.dw_aug.head(qpwork.n_c), stack);
}
The same is true for l.222, where it should be qpmodel.n_eq
.
We will provide a PR with this fix very soon, and we'll add a unittest for the PrimalLDLT
backend.
I also just realized that the bounds are swapped in the code — qp.init(H, g, A, b, C, u, l) instead of qp.init(H, g, A, b, C, l, u).
Probably doesn't matter much for this example/issue, but thought I'd mention it to avoid any mix-ups. 😊
Hi @fabinsch
Thanks for the quick feedback.
I also just realized that the bounds are swapped in the code — qp.init(H, g, A, b, C, u, l) instead of qp.init(H, g, A, b, C, l, u).
This is on purpose, the assert does not trigger with the bounds in the "correct" order. There's probably a better way to consistently trigger it but I didn't manage to find one :(
Fixed via #349.
Hi folks,
First of thanks for all the work that's been put into this library.
I came across a triggering assert while working with the library. I managed to reduce this to the following program:
I'm compiling with CMake:
The generated matrices are:
In RelWithDebInfo/Release, this works just fine:
However in Debug, this raises an assert:
Which happens in the following call stack:
The issue appears to be from here:
(I'm guessing line 222 could generate the same kind of issue?)
The number of rows in
new_cols
are used to iterate overqpwork.dw_aug.head(qpmodel.dim)
so ifnewcols
has more rows thanqpmodel.dim
this triggers an assert. I'm not knowledgeable enough about the underlying algorithm but perhaps changing the dimension passed tohead
to matchnew_cols
dimension is enough here?No alarm is being tripped when asserts are disabled because
qpwork.dw_aug
has enough rows that it doesn't run over the available memory when accessing outside the size of the view range.I have confirmed this happens with both
ros-humble-proxsuite 0.6.5-1jammy.20240728.192252
and the latest version inmain
.There's also no issue if the
PrimalDualLDLT
backend is used.Please let me know if you need more information.