solaris_ci regression
Closed this issue · 5 comments
chipitsine commented
I've added gmake -j2 check || (cat tests/test-suite.log && exit 1)
(probably, I'll add something like that in PR)
build link:
https://github.com/chipitsine/portable/actions/runs/5879700788/job/15944351160#step:4:18195
libressl 3.8.1: tests/test-suite.log
==========================================
# TOTAL: 124
# PASS: 117
# SKIP: 0
# XFAIL: 0
# FAIL: 7
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: aeadtest.sh
=================
./aeadtest.sh: line 7: 7289: Memory fault(coredump)
../test-driver: line 112: 7287: Memory fault(coredump)
FAIL aeadtest.sh (exit status: 267)
FAIL: apitest
=============
== Testing SSL_get_peer_cert_chain()... ==
../test-driver: line 112: 7297: Memory fault(coredump)
FAIL apitest (exit status: 267)
FAIL: gcm128test
================
../test-driver: line 112: 7566: Memory fault(coredump)
FAIL gcm128test (exit status: 267)
FAIL: signertest
================
../test-driver: line 112: 7687: Memory fault(coredump)
FAIL signertest (exit status: 267)
FAIL: ssl_get_shared_ciphers
============================
../test-driver: line 112: 7699: Memory fault(coredump)
FAIL ssl_get_shared_ciphers (exit status: 267)
FAIL: ssltest.sh
================
WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf
LibreSSL 3.8.1
WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf
test sslv2/sslv3
./testssl: line 21: 7731: Memory fault(coredump)
FAIL ssltest.sh (exit status: 1)
FAIL: tlstest.sh
================
./tlstest.sh: line 13: 7855: Memory fault(coredump)
../test-driver: line 112: 7854: Memory fault(coredump)
FAIL tlstest.sh (exit status: 267)
botovq commented
On Wed, Aug 16, 2023 at 07:58:04AM -0700, Ilya Shipitsin wrote:
I've added `gmake -j2 check || (cat tests/test-suite.log && exit 1)`
(probably, I'll add something like that in PR)
Thanks, that would be helpful.
Combining the test failures with the start date of the CI failures this
commit but it can't be the only culprit:
openbsd/src@05958c5
I'm trying a run with that commit reverted:
https://github.com/botovq/libressl-portable/actions/runs/5883380506/job/15955925690
Unfortunately, it will take forever until it runs/completes.
It would be interesting to see backtraces for these memory faults.
I do not really think there is an issue with one of the recent commits
(in particular the one pointed out above). I suspect moreso an issue
with our solaris compat layer that is exposed by some recent changes.
chipitsine commented
I'm trying to get backtrace (from github actions)
chipitsine commented
gcm128test:
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./gcm128test...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000000004066ed in CRYPTO_gcm128_init (ctx=ctx@entry=0x7fffbfffe9a0,
key=key@entry=0x7fffbfffe8a0, block=<optimized out>) at modes/gcm128.c:654
654 ctx->H.u[0] = be64toh(ctx->H.u[0]);
A debugging session is active.
Inferior 1 [process 8232 ] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
botovq commented
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000000004066ed in CRYPTO_gcm128_init ***@***.***=0x7fffbfffe9a0,
***@***.***=0x7fffbfffe8a0, block=<optimized out>) at modes/gcm128.c:654
654 ctx->H.u[0] = be64toh(ctx->H.u[0]);
I suspect the solaris compiler is less lenient with type punning via
union members or something to that effect. Aliasing is such a completely
incomprehensible mess :(
A couple of lines above that access, we write to a different member of
the ctx->H union:
```
652 (*block)(ctx->H.c, ctx->H.c, key);
```
My understanding is that the access to `ctx->H.u[0]` should be legal,
but we should probably double check with people more familiar with the
subtleties of the C standard...
My solaris_ci run with the above mentioned commit reverted had all tests
passing, while a run without the revert still fails:
https://github.com/libressl/portable/actions/runs/5883781410/job/15957179281
chipitsine commented
identical backtrace for signertest
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./signertest...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x000000000054d79d in CRYPTO_gcm128_init (ctx=ctx@entry=0x743ba8,
key=key@entry=0x743ab0, block=<optimized out>) at modes/gcm128.c:654
654 ctx->H.u[0] = be64toh(ctx->H.u[0]);
A debugging session is active.
Inferior 1 [process 8231 ] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]