[openssl.org #1223] make test fails on some systems in 0.9.8a
I have build openssl 0.9.8a on 4 machines, all with sh config no-idea no-threads -fPIC make depend make and tried to run make test afterwards. On all 4 machines the sources compiled fine. However, on 2 of them make test fails. The symptoms are different. I'm currently unsure whether this is a bug in openssl, gcc, or any other part of the systems. All 4 machines are 32bit x86 Linux systems. The working machines are running SuSE 10.0 with gcc 4.0.2 and glibc 2.3.5 and SuSE 9.2 with gcc 3.3.4 and glibc 2.3.3. On a SuSE 9.0 machine, however, with gcc 3.3.1 and glibc 2.3.2 make test deadlocks after: The following command should have some OK's and some failures There are definitly a few expired certificates ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs ../certs/*.pem ../certs/RegTP-5R.pem: /C=DE/O=Regulierungsbeh\xC8orde f\xC8ur Telekommunikation und Post/0.2.262.1.10.7.20=1/CN=5R-CA 1:PN error 10 at 0 depth lookup:certificate has expired OK ../certs/RegTP-6R.pem: /C=DE/O=Regulierungsbeh\xC8orde f\xC8ur Telekommunikation und Post/0.2.262.1.10.7.20=1/CN=6R-Ca 1:PN error 10 at 0 depth lookup:certificate has expired OK ../certs/argena.pem: OK ../certs/argeng.pem: OK ../certs/eng1.pem: OK ../certs/eng2.pem: OK ../certs/eng3.pem: OK ../certs/eng4.pem: OK ../certs/eng5.pem: OK ../certs/thawteCb.pem: OK ../certs/thawteCp.pem: OK ../certs/vsign1.pem: OK ../certs/vsign3.pem: OK ../certs/vsignss.pem: OK ../certs/wellsfgo.pem: OK The process does not consume any CPU time, it just blocks. On a SuSE 8.0 machine with gcc 2.95.3 and glibc 2.2.5 make test fails with starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr make[1]: *** [test_bn] Error 139 make[1]: Leaving directory `/usr/local/src/openssl-0.9.8a/test' make: *** [tests] Error 2 These problems occur with openssl 0.9.8a, but 0.9.7i works fine on all 4 machines. Best regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1223] make test fails on some systems in 0.9.8a
Give it up, the developers aren't interested. I posted a core dump under Solaris and nobody cared enough to look at it. Somebody is not reading e-mail. The question was answered with '[see] ./PROBLEMS, triggered gcc bugs [section].' I am pretty sure they know what the hell is going on. Anything special/subtle/uncommon we know is usually documented in ./PROBLEMS or ./FAQ depending on how often problem is encountered! 0.9.8a obviously makes use of some go-fast supercalifragelistic code that 0.9.7 avoids. I'm sure the developers are more enamoured of this fancy code than of getting 0.9.8 to compile reliably. All supercalifragelistic code can be switched off with no-asm. It's your choice, and if you're so upset about 0.9.8 being more modern, just configure with no-asm. There's a good chance that your problem, like mine, would be solved by completely recompiling gcc, *Both* problems *are* documented in ./PROBLEMS. His problem can be resolved by upgrading binutils. OpenSSL was the -only- source that required the compiler to be recompiled. Not if you configured with no-asm. Now back to the beginning. developers are not interested. Well, no, I'm not interested to say see accompanying documentation over and over again and you're not in position to blaim me, as I do it in my spare time. Cheers. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ideas on replacing where ERR_STATE is stored?
Michael, What does the thundering herd problem have to do with select vs poll? The only typically useful advantages of poll over select that I am aware of are that poll can monitor more descriptors than select and that it can monitor a large number of descriptors more efficiently -- but this efficiency issue has nothing to do with thundering herd. I'm having trouble with the context here. Rich is talking about simply using select/poll to monitor multiple sockets. Thundering herd is a problem when a large number of threads are monitoring the same events. While select/poll can be used in such a way that thundering herd can be a problem, for the simple single-thread select/poll loop it just isn't in the picture -- how can a single thread suffer from the thundering herd problem? Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Sierchio Sent: Tuesday, 18 October 2005 2:49 AM To: openssl-dev@openssl.org Subject: Re: ideas on replacing where ERR_STATE is stored? Steven Reddie wrote: Hi Michael, I'm familiar with that approach, having used it many times myself. The choice of poll over select isn't important since they're basically the same; in fact, poll is sometimes implemented with select. Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. But that's just my opinion... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1223] make test fails on some systems in 0.9.8a
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov Sent: Tuesday, October 18, 2005 5:23 AM To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #1223] make test fails on some systems in 0.9.8a Give it up, the developers aren't interested. I posted a core dump under Solaris and nobody cared enough to look at it. Somebody is not reading e-mail. The question was answered with '[see] ./PROBLEMS, triggered gcc bugs [section].' My bad, then. I did not see that. Seriously! Mea Culpa, I do apologize. I am pretty sure they know what the hell is going on. Anything special/subtle/uncommon we know is usually documented in ./PROBLEMS or ./FAQ depending on how often problem is encountered! The Solaris 8 issue is NOT in the FAQ. Yes, it is in PROBLEMS in 0.9.8 - after you mentioned this I looked at it again and saw the values.c thing. But the answer there is to recompile gcc with values.c HOWEVER I respectfully submit that is is bogus crapola. This should be handled by the configure script, that is why you have it. The entire point of the configure script is to fixup stuff like this. Configure should build a small test program that checks for the Solaris linker bug and if it seg faults then it should put in the no-asm and spit out a message to the effect to patch the compiler or tell the GCC people to fix their compiler. Just my opinion!!! Nothing in PROBLEMS talks about compiling with no-asm as a workaround. 0.9.8a obviously makes use of some go-fast supercalifragelistic code that 0.9.7 avoids. I'm sure the developers are more enamoured of this fancy code than of getting 0.9.8 to compile reliably. All supercalifragelistic code can be switched off with no-asm. It's your choice, and if you're so upset about 0.9.8 being more modern, just configure with no-asm. I'm just bugged that this isn't more documented. The problem with Solaris is that since it ships with no compiler everyone has to download a precompiled binary of gcc. Since these binaries don't have the value.c patch, openssl 0.9.8 compilation is going to blow chunks on a large majority of solaris systems. Not that I'm complaining but the FAQ has a entry for Alpha Tru64 and your going to tell me that is larger deployed base than Solaris x86!! There's a good chance that your problem, like mine, would be solved by completely recompiling gcc, *Both* problems *are* documented in ./PROBLEMS. His problem can be resolved by upgrading binutils. OpenSSL was the -only- source that required the compiler to be recompiled. Not if you configured with no-asm. NOT documented in the PROBLEMS document in the paragraph that talks about the Solaris linker bug. Now back to the beginning. developers are not interested. Well, no, I'm not interested to say see accompanying documentation over and over again Then move some of the stuff out of PROBLEMS and into the FAQ. Or at least put a FAQ question in the FAQ that tells people to read the PROBLEMS document. and you're not in position to blaim me, as I do it in my spare time. I see your not married, then. ;-) Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
