sig abort after kiwi::InternalSolverError about kiwi HOT 19 CLOSED

Well, the crash is expected since the exception is unhandled. However, that exception should never actually be thrown. They are only thrown when the code hits a condition which should never occur. So, this is almost certainly a bug in Kiwi.

Can you whittle down your code into a short reproducible example? That will be much easier for me to debug.

from kiwi.

okay i'll try to do that, but it may be hard, I use kiwi in a quite complex environnement. I'll keep you in touch, thanks for your answer.

from kiwi.

Hello,

with regards to this bug, even if the exception is handled from user code, it will not work if the file that includes kiwi.h is compiled in C++11 mode.

This is because an exception is thrown from DualOptimizeGuard::~DualOptimizeGuard, and, since C++11, destructors are marked noexcept(true) by default, which will cause std::terminate to be called as soon as an exception is thrown :
http://en.cppreference.com/w/cpp/language/destructor

Except that if no exception specification is explicitly provided, the exception specification is considered to be one that would be used by the implicitly-declared destructor (see below). In most cases, this is noexcept(true). Thus a throwing destructor must be explicitly declared noexcept(false).

from kiwi.

Closing this, since there's not much I can do without a reproducible example. Feel free to re-open it if you come up with one.

from kiwi.

I was getting this error too. It was also for a complicated system - one that worked for modest numbers of constraints, but then would crash when more contraints were added.

My uneducated guess as to what is happening is that an "UnresolvableConstraint" error should be thrown, but the system is too complicated for that logic to catch, so the solver crashes. I (think) I can provide code that does this if it helps, but its not a trivial example. (I did attempt to craft a MNWE, but kiwi kept catching the error before updateVariables was called).

However, I found the "fix" was to be more careful about setting constraint weights. I changed most of my constraints to 'strong' instead of the default 'required' (but left a few important ones as 'required', and so far I'm not getting crashes and I'm getting the right results for the solver.

from kiwi.

Reopening since we have another user affected by this.

@jklymak Thanks for chiming in. I'll definitely take a look at a reproducible example, even if it's complicated.

from kiwi.

@sccolbert

OK, great. You can have a look at https://github.com/jklymak/kiwierror

I narrowed down the error to one line, so that helps, I hope. See the Readme.md, but as I said, the problem is fixed if I set the strength to 'strong', whereas I hadn't really read your instructions and was just using the default constraint, which is 'required'.

Note you need matplotlib. I tried a MNWE w/o and couldn't trigger the error. Not blaming matplotlib, but obviously I failed to replicate the complications.

For some context, I'm trying to use kiwi to constrain layout of matplotlib axes. See (an obsolete) https://github.com/jklymak/mplconstrainedlayout

Thanks a lot!

from kiwi.

Looking at the dump of the solver before adding the last constraint, I noticed that there is one infeasible constraint that does not exist when adding earlier constraints so it may be related. I will keep digging.
Playing around more, I actually do not see an infeasible constraints before adding the last one (I do not know what was going on). However I found some other interesting thing:

• the bug does not always show up at the same stage, I see crashes at symbol 387, 687, 1383.
• in some cases there is no error !
• each time I see a failure the entering row contains only dummy symbols
  I guess my next step will to actually read the cassowary paper ...

from kiwi.

Based on my (limited) understanding of the algorithm, it seems to me that if an all dummy row enters the infeasible rows it should be discarded in the dualOptimize step since this constraint is redundant and entered the infeasible rows list only because the near zero constant happens to be negative.

What seems to me like a proper fix would be to add an allDummies check in https://github.com/nucleic/kiwi/blob/master/kiwi/solverimpl.h#L608. This means that we will look for an entering symbol only if the infeasible row is non dummy and furthermore this means that each time we run a dualOptimize we will clean the infeasible rows. I believe it is best to run the check this late since the row may have been added to the infeasible rows but may have become a dummy row after some pivot operations.

@sccolbert I would really appreciate your feedback here.

from kiwi.

Actually we should also check the constant for near zero. And if we only got dummies but non-zero constant I do not know what we should do !

from kiwi.

@jklymak I believe I fixed the issue as part of #56. Could you give this branch a try and see if it behaves better in matplolib ?

from kiwi.

This should be fixed in 1.1.0

from kiwi.

This error can still be thrown with v1.2.0 when using MPL constrained layouts it seems.
I just encountered this error for the first time in 3 years making the same figure 1000s of times, so it seems that it is incredibly rare.
I therefore do not have a minimal reproducible example.

from kiwi.

Ew, sorry about that.

FWIW, Matplotlib is probably going to rewrite constrained_layout, and hopefully this won't be possible any longer.

from kiwi.

@jklymak do you know more about matplotlib plans. I have wanted to have a look at the implementation for a long time bit never got around to actually doing it.

from kiwi.

Sure, its this PR: matplotlib/matplotlib#17494

The main change is that there are far fewer constraints (they are by columns and rows of gridspec rather than for each axes in the gridspec) and that what is constrained is the margins around axes, so that the axes always fill the figure. Before we had the problem that zero was an acceptable solution of the constraints (i.e. a=b=2c has a trivial solution) and we had no outer constraint to fix that. It worked, but it was fragile.

from kiwi.

Out of curiosity are you planning to have any in-figure constraints (for example to place the colorbar next to a plot) separate from the rest (basically having a bit more hierarchy than the old code) ? I will try to have a look at the PR.

from kiwi.

@MatthieuDartiailh Not quite sure what you mean. If it weren't for colorbars, constrained_layout would be pretty easy 😉 - so most of the work was getting colorbars to work well. Is there a case that doesn't work? Its still feature matched to what's described in https://matplotlib.org/tutorials/intermediate/constrainedlayout_guide.html though colorbar placement has changed in the new code.

from kiwi.

Sorry about the noise, I am so used to attaching a colorbar to one graph and thinking of that as one unit in the grid that I forgot about other usecases. I really to check more the documents your wrote.

from kiwi.