RFR: 8333277: ubsan: mlib_ImageScanPoly.c:292:43: runtime error: division by zero

[Phil Race]

On Wed, 12 Jun 2024 08:02:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jdk jtreg tests with ubsan enabled binaries on Linux x86_64, I get the warning below.
> This shows up in a couple of tests, for example
> java/awt/image/mlib/MlibOpsTest.jtr
> java/awt/image/Raster/TestChildRasterOp.jtr
> 
> src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c:292:43: runtime error: division by zero
>     #0 0x7fe6d958b862 in mlib_AffineEdges src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c:292
>     #1 0x7fe6d958bb5d in mlib_ImageAffine_alltypes src/java.desktop/share/native/libmlib_image/mlib_ImageAffine.c:179
>     #2 0x7fe6d9e9b398 in Java_sun_awt_image_ImagingLib_transformBI src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:922
>     #3 0x7fe76f00ae7b (<unknown module>)
> 
> The issue has been discussed with Phil Race (see https://bugs.openjdk.org/browse/JDK-8333277) and the division by zero has been already handled in the coding.
> However we can avoid it  (and make ubsan happy) and in this case also do a few operations less.

I have no particular objection to this but I do not actually think it is worth it.
The  / 0 is not a real problem and there's no goal of hunting these down and changing
code that knows perfectly well what it is doing and can handle it just fine.
This whole ubsan thing is just random findings based on what tests we have.
We'll never be ubsan clean and I'm not sure it is advisable in all cases.
And I'm not sure "==" test doesn't mean the slope won't be infinite anyway because
of the wonders of FP arithmetic, so the IS_FINITE test has to remain of course.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19674#pullrequestreview-2113508053