Two backtraces ... and a hangup

[Richard Theil]

Am 10.04.2015 um 13:02 schrieb Boudewijn Rempt:

> I think that we shouldn't build the Neon packages with asserts enabled.. I can replace the asserts by returns, then that wouldn't happen.

Hehe; not exactly my idea of software development ;) They're there for a reason and from what I can see, it would not be a good idea to call setControlPoint1 with Not-A-Number (or Infinity?) values in the first place.

> From what you say, it sounds like it's really easy for you to reproduce, but I haven't managed yet! Could you install the debug symbols and try to reproduce?

I'll have a look into it as i get some play time. However, I just gave it a quick look again, just using the mouse, to see whether issues are maybe dependent on the ancient Wacom hardware. Test case was painting the kanji chars at unicode 5b50, 5f8b, and 76f4. Wacom was disconnected, Mouse was an Apple trackball mouse. Built in T500 TrackPad/Point available, but untouched.

I ran into a hangup after about a dozen characters drawn. Not a crash, but a seemingly (*) endless looping output of "reached MAX_RECURSIVE_DEPTH" in KarbonSimplifyPath::subdivideAux. That function in turn calls KoPathPoint::setControlPoint1. Coincidence?

(*) As I read some "calligra-2.9.2" code on the web, It should limit the subdivisions off at MAX_RECURSIVE_DEPTH. So it might not have been technically endless, but just an attept to print around 1024^2/2 lines, which would occur if some input value of the original curve is so NaN that the final comparison in isSufficentlyFlat always returns false.

Rich

by the way, in isSufficentlyFlat, you could factor out the division by (SUBDIVISION_COEFF*SUBDIVISION_COEFF) to save a few cycles. Might even help, because that's probably called rather often.