http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78523 --> http://bugs.winehq.org/attachment.cgi?id=78523 plsql-widen_cap-adds-NaN_better-workaround.txt
(In reply to Esme Povirk from comment #5)
Where did the NaNs come from? If the application added them to a path, we should see if native allows such a path to be built at all. If they were introduced by GdipWidenPath, there's probably a bug there.
GdipWidenPath calls widen_open_figure, which calls widen_cap. Unfortunety in widen_cap the branch LineCapRound is taken, and segment_length gets a value of 0.0, which causes dx and dy to receive the NaN because of a division by zero, which gets used in the following calls to add_path_list_node.
In widen_cap are more uses of segment_length in the other branches, which may also be vulnerable.
The now attached file contains a workaround which avoids using this branch when segment_length is zero.