Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Benjamin Kaduk via openssl-dev
On 05/12/2017 03:05 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > I’m not sure. It may well be that it “simply” takes all the memory > over, so there is no way for anything else to start and do the clean-up… > Hmm, I wonder if a top(1) started before the tests would keep running, in the case that

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Short, Todd via openssl-dev
It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB... -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." > On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > > Todd> Yes, it’s likely this is due

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Short, Todd via openssl-dev
Uri: Look at https://github.com/openssl/openssl/pull/3455 I limited the test that hung your machine to Linux. Rich: this removes the OpenSSL_assert() you see. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Blumenthal, Uri - 0553 - MITLL
The obvious candidate for closer inspection is a few commits previous, commit 7031ddac94d0ae616d1b0670263a9265ce672cd2 Author: Todd Short Date: Thu May 11 15:48:10 2017 -0400 which adds test cases intended to trigger the edge cases being fixed. Point well-taken. ;-)

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Benjamin Kaduk via openssl-dev
On 05/12/2017 02:05 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 5/12/17, 2:49 PM, "openssl-dev on behalf of Benjamin Kaduk via > openssl-dev" openssl-dev@openssl.org> wrote: > > ➢ I’m sorry to report that in the current OpenSSL 1.1 master

[openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Blumenthal, Uri - 0553 - MITLL
I’m sorry to report that in the current OpenSSL 1.1 master running “make test” freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, current Github master. Here’s the configuration: ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Benjamin Kaduk via openssl-dev
On 05/12/2017 01:34 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > I’m sorry to report that in the current OpenSSL 1.1 master running > “make test” freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, > current Github master. Here’s the configuration: > A commit hash would be more useful than

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Salz, Rich via openssl-dev
Current master 1d0f116 fails on my machine. ../test/recipes/90-test_secmem.t .. 1..1 # Subtest: ./secmemtest 1..1 # INFO: @ test/secmemtest.c:65 # Possible infinite loop: allocate more than available # INFO: @ test/secmemtest.c:71 # Possible infinite loop: small arena

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Blumenthal, Uri - 0553 - MITLL
On 5/12/17, 2:49 PM, "openssl-dev on behalf of Benjamin Kaduk via openssl-dev" wrote: ➢ I’m sorry to report that in the current OpenSSL 1.1 master running “make test” ➢ freezes up the machine. Mac OS X 10.11.6, Xcode-8.2,

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Benjamin Kaduk via openssl-dev
On 05/12/2017 02:15 PM, Benjamin Kaduk via openssl-dev wrote: > From just looking at the code, the only question that comes to mind is > whether you have a 32- or 64-bit size_t in the build environment in > question, which is unlikely to cause a eureka moment :( (The test runs happily on my

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

2017-05-12 Thread Short, Todd via openssl-dev
Yes, it’s likely this is due to the amount of memory available in the machine. I tried to use reasonable values, but apparently not reasonable enough. This is certainly a case where we’re trying to stretch the limits of the hardware; so it may not be an appropriate test for all hardware. In