OpenSSL and panama-foreign

[Maurizio Cimadamore]

After many failed attempts at narrowing it down, I change direction and 
commented this line on panama-foreign

https://github.com/openjdk/panama-foreign/blob/ea1e0d6e62558d31084250ce07c2334f6f8ebc0f/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java#L116

That is, I removed the shared scope handshake. Without the handshake, 
there's no more crashes.

This seems to point at some issues with the shared scope logic 
interacting badly with upcall intrinsics. But neither areas have changed 
significantly since 17, which makes this very odd.

Maurizio

On 10/11/2021 19:09, Rémy Maucherat wrote:
> On Wed, Nov 10, 2021 at 7:19 PM Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> I've been able to reproduce, with tomcat and all. Seeing all the crashes
>> you are seeing.
>>
>> After some digging, it seems like the crash does not occur with these
>> parameters:
>>
>> export
>> JAVA_OPTS="-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false
>> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign"
>>
>> In other words, the intrinsification support for _upcalls_ seems to be
>> creating issues here.
>>
>> Please confirm that this setup works for you.
> I can confirm the setting fixes the problem (using the PR, I didn't
> switch back to the panama-foreign branch). Great job on catching it !
>
> Rémy
>
>> Cheers
>> Maurizio
>>
>>
>> On 10/11/2021 17:56, Maurizio Cimadamore wrote:
>>>> Ok, quick test then since this is very interesting. It cores (exact
>>>> same ones).
>>>>
>>>> I'll work on all the other items now (thanks for all the homework ;) ).
>>> Thanks for testing. This leaves us with two options: some general JDK
>>> change which brought some latent issue to the fore, or some specific
>>> regression in the linker support. On top of my head the latter doesn't
>>> make much sense - since the new panama changes only affect the API,
>>> not the VM internals.
>>>
>>> But I'll keep testing on my end.
>>>
>>> Maurizio
>>>
>>>
>>>> Rémy
>>>>
>>>>> Maurizio
>>>>>
>>>>> On 10/11/2021 11:20, Rémy Maucherat wrote:
>>>>>> In gdb, the debug is:
>>>>>>
>>>>>> #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420
>>>>>> 4420            if (s->s3->alert_dispatch)
>>>>>> (gdb) print s
>>>>>> $1 = (SSL *) 0x0
>>>>>>
>>>>>> With the corresponding source:
>>>>>> 4400    int ssl3_shutdown(SSL *s)
>>>>>> 4401    {
>>>>>> 4402        int ret;
>>>>>> 4403
>>>>>> 4404        /*
>>>>>> 4405         * Don't do anything much if we have not done the
>>>>>> handshake or we don't
>>>>>> 4406         * want to send messages:-)
>>>>>> 4407         */
>>>>>> 4408        if (s->quiet_shutdown || SSL_in_before(s)) {
>>>>>> 4409            s->shutdown = (SSL_SENT_SHUTDOWN |
>>>>>> SSL_RECEIVED_SHUTDOWN);
>>>>>> 4410            return 1;
>>>>>> 4411        }
>>>>>> 4412
>>>>>> 4413        if (!(s->shutdown & SSL_SENT_SHUTDOWN)) {
>>>>>> 4414            s->shutdown |= SSL_SENT_SHUTDOWN;
>>>>>> 4415            ssl3_send_alert(s, SSL3_AL_WARNING,
>>>>>> SSL_AD_CLOSE_NOTIFY);
>>>>>> 4416            /*
>>>>>> 4417             * our shutdown alert has been sent now, and if it
>>>>>> still needs to be
>>>>>> 4418             * written, s->s3->alert_dispatch will be true
>>>>>> 4419             */
>>>>>> 4420            if (s->s3->alert_dispatch)
>>>>>> 4421                return -1;        /* return WANT_WRITE */
>>>>>> 4422        } else if (s->s3->alert_dispatch) {
>>>>>> 4423            /* resend it if not sent */
>>>>>> 4424            ret = s->method->ssl_dispatch_alert(s);
>>>>>> 4425            if (ret == -1) {
>>>>>> 4426                /*
>>>>>> 4427                 * we only get to return -1 here the 2nd/Nth
>>>>>> invocation, we must
>>>>>> 4428                 * have already signalled return 0 upon a previous
>>>>>> invocation,
>>>>>> 4429                 * return WANT_WRITE
>>>>>> 4430                 */
>>>>>> 4431                return ret;
>>>>>> 4432            }