On 9/17/2018 2:20 PM, Rainer Jung wrote:
> Am 17.09.2018 um 20:59 schrieb Daniel Ruggeri:
>> Hi, all;
>>     I have been delayed executing the automation because the test
>> suite seems to be hanging for me. This appears to be consistently
>> during t/ssl/varlookup.t as that is the only process other than httpd
>> running in this container during the hang. When killing httpd, the
>> failures reported start at test 35 with err "Failed test 35 in
>> t/ssl/varlookup.t at line 109 fail #35" and continue to 83.
>
> Which platform, which version of OpenSSL?
>

Hi, Rainer;
   Sorry - I know it wasn't a very good report. I was just seeing if
anyone has experienced a similar holdup. In fact, I let it run while
tending to other things and came back to see it had completed (but
failed), so perhaps it's not hung, but rather very slow.

I'm using Debian 9 (stretch) in a container running on a 3.16.51-3
kernel. OpenSSL 1.1.1 is inside as well as several other dependencies...
these are the "latests" that my build scripts grabbed:
system:
  kernel:
    name: Linux
    release: 3.16.0-4-amd64
    version: #1 SMP Debian 3.16.51-3 (2017-12-13)
    machine: x86_64

  libraries:
    openssl: "1.1.1"
    openldap: "2.4.46"
    apr: "1.6.5"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.5"
    nghttp2: "1.33.0"
    zlib: "1.2.11"
    pcre: "8.42"
    libxml2: "2.9.8"
    php: "5.6.38"
    lua: "5.3.5"
    curl: "7.61.1"

...which reminds me... time to update my kernel :-)

>>     If anyone has experience with this area of the test suite,
>> pointers definitely welcome. Otherwise, I'll start poking at it.
>
> You can run the tests with
>
> t/TEST -v -order=repeat
>
> which might give more insight.
>
> My passing tests for 2.4.34 e.g. logged
>
> ...
> # testing : SSL_CIPHER_EXPORT
> # expected: 'false'
> # received: 'false'
> ok 35
> # testing : SSL_CIPHER_ALGKEYSIZE
> # expected: qr/^\d+$/
> # received: '128'
> ok 36
> # testing : SSL_CIPHER_USEKEYSIZE
> # expected: qr/^\d+$/
> # received: '128'
> ok 37
> # testing : SSL_SECURE_RENEG
> # expected: qr/^(false|true)$/
> # received: 'true'
> ok 38
> ...
>
> and the comments always belong to the "ok" or "not ok" line that
> follows the comments. So test 35 was the "SSL_CIPHER_EXPORT" test at
> that time. I doubt it actually has to do with that.
>
> You might look at the thread stacks (with the gdb "bt" command or
> similar) of the hanging httpd processes to gather more info.
>
> Any errors in the httpd error log, like "deadlock detected" etc.?

Nothing stood out, but I did not debug too deeply. I'll let this next
test run completely and do some poking around. Perhaps I was just
impatient... but I don't recall the suite taking that long to run.

Depending on how this goes, I may pause T&R until I can confirm an issue
on my test rig, the server or the test code. If anyone else is able to
build and verify that TLS w/ 2.4.x branch works A-OK for them, I'd be
fine with proceeding - just being abundantly cautious.

>
> Regards,
>
> Rainer

-- 
Daniel Ruggeri

Reply via email to