EVALUATION
Name: spR10137 Date: 11/19/2003
The reason of crash is using the macros anglesOct1Cos() in
method cubicCircleApproximation of dcPathStroker.c file.
Array anglesOct1CosTable has only (anglesDEG045 + 1) elements,
i.e. 513. But dcPathStroker.c has two places where we
call this macros with value like ((anglesUnsignedSpan(a0, a1) + 1)/ 2).
But method anglesUnsignedSpan() returns values from range
[anglesDEG000, anglesDEG180], so divide by 2 gives us range
[anglesDEG000, anglesDEG090], i.e. [0, 1024]. The same for
method anglesSignedSpan().
Usual application uses ductus renderer when we have mapped
memory at (anglesOct1CosTable + 1024) address. But small applications
like this test can involve ductus code when we do not have
mapped memory at address above. So we have segmentatioin fault.
There are only two points in ductus code where we use cos and
sin macroses directly. All other code uses more safe methods
anglesCos() and anglesSin(). So I propose to change macroses
by special methods calls.
======================================================================
Name: spR10137 Date: 11/26/2003
Real reason of bug is wrong data we have in point described
above. So fix should provide good formed data in procesCubic()
and processQuadratic() methods of dcPathSroker.c file.
Bad formed data comes from recursion level limitation. We add
"bad" curves to path if max level acheved. We can add lines
instead because this segment is less than 1/16,000,000 of curve
length. So we'll have safe (macros friendly) angle values for
further calculations. Thanks to Jim.
======================================================================
|
Java