search

wolfSSL / wolfssl

The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3 and DTLS 1.3!
https://www.wolfssl.com
GNU General Public License v2.0
2.29k stars 818 forks source link

"make check" fails #2569

Closed chipitsine closed 4 years ago

chipitsine commented 4 years ago

please see

https://travis-ci.com/chipitsine/wolfssl/builds/135339038

chipitsine commented 4 years ago

btw, maybe enable travis-ci ?

JacobBarthelmeh commented 4 years ago

Hi chipitsine, I took a look at the link. Is there restrictions going on for creating and reading files or possibly with threads? Tried reproducing it with the commands;

git clone --depth=50 --branch=master https://github.com/chipitsine/wolfssl.git wolfssl-chipitsine
cd wolfssl-chipitsine/
./autogen.sh 
./configure CC=clang
make check

May I also see what the results of "cat ./tests/unit.log" is after the failure to see where in the unit tests it's reporting an issue? We'll consider travis-ci, for the moment when setting up the CI it was done with Jenkins.

Regards, Jacob

chipitsine commented 4 years ago

cat ./tests/unit.log is available on travis (however it is collapsed)

gcc amd64: https://travis-ci.com/chipitsine/wolfssl/jobs/253801183#L738

clang amd64: https://travis-ci.com/chipitsine/wolfssl/jobs/253801185#L734

chipitsine commented 4 years ago

I rebased to current master

https://travis-ci.com/chipitsine/wolfssl/jobs/254584958#L894

Error: (-238): ASN CA path length larger than signer error

chipitsine commented 4 years ago

also,

https://travis-ci.com/chipitsine/wolfssl/jobs/254584958#L5552

wolfSSL error: tcp connect failed

where does it try to connect to ? tests are run as non privileged user, it is not allowed to bind privileged tcp ports

JacobBarthelmeh commented 4 years ago

It looks like the tcp connect is not getting established. (lower level than wolfSSL code). That test should not need higher privileges but I noticed that the tests are failing on the first case where "-h localhost" is set with the client. Maybe the localhost value is not getting resolved in the travis environment when it kicks off the test? Is it successful if removing the explicit "-h localhost" which will go back to default of explicitly setting the host connecting to as 127.0.0.1?

Removing the instances of "-h localhost" in

$ git grep "\-h localhost" tests/
tests/test-fails.conf:-h localhost
tests/test-fails.conf:-h localhost
tests/test-fails.conf:-h localhost
tests/test-fails.conf:-h localhost
tests/test-fails.conf:-h localhost
tests/test.conf:-h localhost
tests/test.conf:-h localhost
tests/test.conf:-h localhost
tests/test.conf:-h localhost
tests/test.conf:-h localhost
chipitsine commented 4 years ago

travis runs on GCE, which is not ipv6 capable. so, localhost is tricky thing. depending on how you treat it.

if you have some filter to include / exclude tests, you can set them to exclude some tests from travis. or switch to 127.0.0.1 (which is "ipv4 only" lock)

chipitsine commented 4 years ago

well, I have an idea. since you have not chosen travis-ci yet, maybe choose Azure DevOps (or even GitHub actions) ?

travis seems to be too boring sometimes

chipitsine commented 4 years ago

he-he

https://github.com/chipitsine/wolfssl/commit/721e68682ec963f34a78e48a171031fe8e3f35e2/checks?check_suite_id=305779144

JacobBarthelmeh commented 4 years ago

travis runs on GCE, which is not ipv6 capable. so, localhost is tricky thing. depending on how you treat it.

if you have some filter to include / exclude tests, you can set them to exclude some tests from travis. or switch to 127.0.0.1 (which is "ipv4 only" lock)

I'll see about opening a PR to remove -h localhost. I think that having the test resolve localhost is not critical to that test suite......but will check internally.

JacobBarthelmeh commented 4 years ago

well, I have an idea. since you have not chosen travis-ci yet, maybe choose Azure DevOps (or even GitHub actions) ?

travis seems to be too boring sometimes

We took a quick look at GitHub checks (maybe that is different than actions?), it looked interesting. The person who looked though, thought it would kind of be a replacement to the Jenkins CI tests already in place that run on pull requests. I'm not sure that we have looked at Azure DevOps yet though, I'll bring that up. I suspect we will stay with Jenkins with the current test rig having a large number of tests ran on it and developer familiarity with creating tests using Jenkins. That is unless one of the other CI testing solutions provides something that we need but can not currently do.

It looks like the make distcheck is failing due to the touch on ./wolfssl/wolfcrypt/async.h not creating the file. This happens when ./autogen.sh is ran. For the step autoreconf please run ./autogen.sh instead of calling autoreconf directly. That .sh script runs autoreconf and touchs some files necessary for distribution. The autogen.sh script also looks for the .git directory and adds Warrning=all,error in that case.

chipitsine commented 4 years ago

Jenkins is OK as long as you wish to maintain your own servers. Jenkins is even more powerful than any cloud CI