VaList is buggy on Java 17?

[Mark Hammons]

On further thought, this bug is a bit more insidious than I thought. I
cannot just shove Int into the VaList as a Long because c functions people
are interfacing with may be expecting Int data.

Also, I believe it happens when constructing the VaList, not reading data
out of it. When I have C construct the VaList out of a variadic input +
count and pass the va_list into an up all into java, all the elements of
the VaList are read appropriately.

I will confirm this myself by passing a VaList into C and having it sum all
the values and comparing with the expected result. I will also test if
interspersing Longs into the build of the VaList makes the bug disappear.

On Thu, Apr 20, 2023, 09:05 Mark Hammons <markehammons at gmail.com> wrote:

> I'm very sorry, I forgot to show you the test failure I was getting:
>
> ==> X fr.hammons.slinc.Transfer17Jitted.varargs can be embedded in structs
>  0.225s munit.ComparisonFailException:
> /home/mhammons/Documents/slinc/core/test/src/fr/hammons/slinc/TransferSpec.scala:235
> 234:          ints.foreach: value =>
> 235:            assertEquals(va.get[CInt], value, "conversion test")
> 236:
> conversion test
> => Obtained
> 0
> => Diff (- obtained, + expected)
> -0
> +1
>
> Failing seed: G74hsXncaBhRJ5gYO0IoJVCp1DhYmXm0CSeK35JkZPN=
> You can reproduce this failure by adding the following override to your
> suite:
>
>   override def scalaCheckInitialSeed =
> "G74hsXncaBhRJ5gYO0IoJVCp1DhYmXm0CSeK35JkZPN="
>
> Falsified after 9 passed tests.
> > ARG_0: List(0, 0, 0, 0, 0, 0, 0, 1)
> > ARG_0_ORIGINAL: List(-1588110949, -1261571563, 0, -554817481, 0,
> 330801625, 1, 446849842, 1147609259)
>
> What these results indicate is that after the 7th Int retreived from the
> VaList, the VaList starts returning 0 instead of the value originally
> passed in.
>
> On Thu, Apr 20, 2023 at 9:00 AM Mark Hammons <markehammons at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I know that the panama project is pushing forward on java 20 and 21 right
>> now, and java 17 is probably not a great concern for you all at the moment,
>> but I was testing VaList support in my library, Slinc, and it seems to be
>> flaky on Java 17.0.5. The test in question goes like so:
>>
>>   property("varargs can be embedded in structs"):
>>       forAll: (ints: Seq[CInt]) =>
>>         val numTake = 8
>>         Scope.confined:
>>           val va = VarArgsBuilder.fromIterable
>>             (
>>               ints.map(a => a: Variadic).take(numTake)
>>             )
>>             .build
>>
>>           val x = va.copy()
>>
>>           val p = Ptr.copy(E(x))
>>
>>           ints.take(numTake).foreach: value =>
>>             assertEquals(va.get[CInt], value, "conversion test")
>>
>>           ints.take(numTake).foreach: value =>
>>             assertEquals((!p).list.get[CInt], value)
>> Originally in this test I was testing if I could write a VaList to a
>> struct and get it back out and pull the values out of it appropriately.
>> What I noticed is that if the number of integer values in a row passed into
>> VaList is 8 or greater, my test fails. 7 or less ints and the test passes.
>> On the Java 19 implementation, this does not happen, nor does this happen
>> when I pass a great deal more parameters (but more varied in types, some
>> longs, some pointers, some structs). This test passes if I randomly
>> generate Long values and pass those into the VaList.
>>
>> This is not a critical bug by any means. I can sidestep the issue by
>> encoding all lower integral types into Long in the java 17 runtime for my
>> library. I just wanted to bring this to your attention because it's a weird
>> issue that java 17 users of the foreign api may hit.
>>
>> Thanks for your time,
>> Mark Hammons
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230420/f909009b/attachment.htm>