Re: [openssl.org #444] Win32 crash in PEM_read_X509
Did you build a debug version of OpenSSL to link against for the debug build? This isn't handled automatically and you need to change it so it picks up and uses the debug libraries. Nope. that would explain it. criss-crossing MS multi-threaded libs is always a problem. I was using my debug build (the release was probably set up somewhat incorrectly since I had not touched it yet), so I was using a mismatched pair of libs. thanks for the clarification. michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
Oh. That could account for the problem if OpenSSL is using the release build of the multi-threaded DLL's and my build of tunala is using the debug ones. I assume that was on the release build that you changed it, right? If on the debug build it should be correct to use the debug multithreaded DLL, since that is what the debug build of SSL should be built with (or maybe that is the problem). michael At 10:26 PM 1/16/2003 +0100, you wrote: [[EMAIL PROTECTED] - Thu Jan 16 18:39:44 2003]: what did you do to get tunala to compile under Win32? Oh, that. I have been meaning to send Geoff the diff so it could get merged into the code base. I'll get to it some day. I had to wrap up sockets a little and make a few mods in ip. Here is a zip of it with the DSP. Some project paths may be off since this was hacked together, but it should be close. The makefile.am is the makefile the MSVC spit out from the DSP. Thanks. I tried that and it did crash with tunala and those options. However the code generation is set to 'Debug Multithreaded DLL' changing it to 'Multithreaded DLL' and it doesn't crash at that point any more... Is that the problem or have I missed something somewhere? Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
At 06:02 PM 1/15/2003 +0100, you wrote: If you just can't figure out Just to clarify. The posted patch is not so to say try-your-luck thing, it *does* get me through the ms\test. Understood, but it was unclear if it fixed the bug I posted in the PEM read, which is very likely a similar optimization problem. But then you have to remember to go fix it some day and remove the #pragma. ??? Fix what? It's the compiler that needs to be fixed... A. ;) You are absolutely right. A few of us hammered on the MSVC group a couple years back, but it hasn't solved all those optimizer bugs (7 actually was worse for a while). However, if you put in the work around and they do get off there butts to fix it, you have to remember to pull out your work around. michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
what did you do to get tunala to compile under Win32? Oh, that. I have been meaning to send Geoff the diff so it could get merged into the code base. I'll get to it some day. I had to wrap up sockets a little and make a few mods in ip. Here is a zip of it with the DSP. Some project paths may be off since this was hacked together, but it should be close. The makefile.am is the makefile the MSVC spit out from the DSP. michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
Yes, that is a common one, though it was more prevalent in early MSVC7
(.NET) than in MSVC6. Another common problem is nested for loops.
If you just can't figure out why a particular function is generating bad
asm code, it is also possible to use #pragma optimize(off,0) (syntax
might be slightly off) around just the function(s) that is failing, rather
than turn off optimizations globally. But then you have to remember to go
fix it some day and remove the #pragma.
michael
At 02:58 PM 1/15/2003 +0100, Andy Polyakov via RT wrote:
One is that AES using 192 or 256 bit ciphers produces the wrong result.
Have you traced into it at all?
Try this:-)
--- ./crypto/aes/aes_core.c.origWed Nov 13 15:01:18 2002
+++ ./crypto/aes/aes_core.c Wed Jan 15 01:54:08 2003
@@ -750,7 +750,7 @@
rk[2] = GETU32(userKey + 8);
rk[3] = GETU32(userKey + 12);
if (bits == 128) {
- for (;;) {
+ while (1) {
temp = rk[3];
rk[4] = rk[0] ^
(Te4[(temp 16) 0xff] 0xff00) ^
@@ -770,7 +770,7 @@
rk[4] = GETU32(userKey + 16);
rk[5] = GETU32(userKey + 20);
if (bits == 192) {
- for (;;) {
+ while (1) {
temp = rk[ 5];
rk[ 6] = rk[ 0] ^
(Te4[(temp 16) 0xff] 0xff00) ^
@@ -792,7 +792,7 @@
rk[6] = GETU32(userKey + 24);
rk[7] = GETU32(userKey + 28);
if (bits == 256) {
- for (;;) {
+ while (1) {
temp = rk[ 7];
rk[ 8] = rk[ 0] ^
(Te4[(temp 16) 0xff] 0xff00) ^
Well, just to get through the ms\test, only last change is sufficient.
No, it doesn't make sense, compiler bugs don't usually do. This is
already second occasion when I run into such problem. I.e. when
compiler generates bad code for for(;;), but not for while(1).
Last time it was egcs... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
That would certainly seem like a good first step. Have you traced into it at all? I.e. have you run with debug setup and seen a stack trace s.t. you know the function that is crashing and what variable is bad (a null pointer or something)? IF so, I may be able to provide the work around code. I haven't had time to recompile the debug version and run it in the debugger to see what is really happening. Doubt I'll get to it for quite a while, either. But I do know some of the common problems and, if I see the code that is generating faulty code I might see a simple revision. michael At 02:05 AM 1/14/2003 +0100, you wrote: [steve - Fri Jan 10 01:33:03 2003]: I've managed to download SP5 and the processor add on pack. With VC++ 6.0 and SP5 only it passes all tests. With VC++ 6.0, SP5 and processor add on it misbehaves and things like AES give invalid results. After playing around with various options it seems that disabling global optimization with /Og- (add to CFLAG in ntdll.mak) makes it pass the tests and AES works again. Disabling it with a #pragma in aes_core.c also fixes AES but from your description there are other problems too. Now I've got to work out how to uninstall this processor add on pack... Ugh, the only way to remove the processor add on pack seems to be a complete uninstall and reinstall. I think the best we can do with this compiler issue is to document the problem with the processor add on pack (in INSTALL.W32 and possibly the FAQ) and include the workaround. Adding /Og- in general seems to disable some quite extensive optimization and would be overkill because systems without the add on pack aren't affected. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #444] Win32 crash in PEM_read_X509
html body Version 0.9.7 release version from Dec 31, 2002br Compiled using MSVC6 sp6 with Masmbr OS: Windows XP Homebrbr When PEM_read_X509 is called in certain circumstances you get an unhandled exception. I thought it was universal, but I found a test case in the quot;how to reproducequot; below that did not crash.nbsp; NOTE: The same bug may be the cause of the segmentation fault bugs listed (408 and 430) when trying to use openssl to convert PEM certificates on Unix.brbr This bug has been posted by several people on the mailing.openssl.users list, but I have not seen a reply, nor did I see it listed in the tracker's current bug list.brbr It is easy to replicate using the tunala demo.nbsp; Run the first example using the input parameters:br font face=Courier New, Courierx-tabnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/x-tab./tunala -listen localhost:8080 -proxy localhost:8081 -cacert CA.pem -cert A-client.pem -out_totals -v_peer -v_strictbrbr /fontHowever, if you remove the quot;-cert A-client.pemquot; and leave the quot;-cacert CA.pemquot; it does not crash.brbr x-sigsepp/x-sigsep Michael Hunleybr Senior Engineerbr PocketPurchase, Inc. /body /html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
At 02:14 AM 1/9/2003 +0100, you wrote: [[EMAIL PROTECTED] - Wed Jan 8 22:09:03 2003]: html body Please don't post using HTML... Sorry, I did not know that I had. Wasn't this post from the tracker on the OpenSSL site? If not, it must be some setting I have accidentally on in Eudora or something I copied and pasted without knowing it was in HTML. Again, my apologies. (If it is Eudora, then this should also have the same problem ;P). I think it is the styled signature from Eudora..will fix if so. Version 0.9.7 release version from Dec 31, 2002 Compiled using MSVC6 sp6 with Masm Where is SP6 for MSVC6? I can only see SP5 on MS site... Typo..it is SP5. OS: Windows XP Homebrbr When PEM_read_X509 is called in certain circumstances you get an unhandled exception. I thought it was universal, but I found a test case in the quot;how to reproducequot; below that did not crash.nbsp; NOTE: The same bug may be the cause of the segmentation fault bugs listed (408 and 430) when trying to use openssl to convert PEM certificates on Unix.brbr This bug has been posted by several people on the mailing.openssl.users list, but I have not seen a reply, nor did I see it listed in the tracker's current bug list.brbr It is easy to replicate using the tunala demo.nbsp; Run the first example using the input parameters:br font face=Courier New, Courierx- tabnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/x-tab./tunala -listen localhost:8080 -proxy localhost:8081 -cacert CA.pem -cert A-client.pem -out_totals -v_peer -v_strictbrbr /fontHowever, if you remove the quot;-cert A-client.pemquot; and leave the quot;-cacert CA.pemquot; it does not crash.brbr x-sigsepp/x-sigsep Michael Hunleybr Senior Engineerbr PocketPurchase, Inc. /body /html The issue of various things crashing under Win32 is raised quite often. In almost all cases its the multithreaded DLL runtime issue (see FAQ). No, all code was compiled with multi-threaded DLL in the code generation tab. If that is incorrect I get a much earlier crash. Assuming that isn't the case I've also just been tracing the cause of a problem with VC++ SP4 with the processor pack. It was giving incorrect results for 192 and 256 bit AES and different results entirely with the same keys and the 'enc' command line program. Whereas on XP home on my setup VC++ 6.0 with SP3 is fine. I haven't been able to check out SP5 or the processor pack myself but it looks like some kind of compiler bug. Quite likely...MSVC is known to have quite a few. I haven't delved into the build settings for the libs yet, what kind of optimizations are turned on? Steve. michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #441] bug in win32 test
OpenSSl v0.9.7 on Windows XP Home Using MSVC 6 sp 5 with Masm I'm not sure this is a bug or an issue with network connections. I compiled the source and ran the test app (ms/test.exe) and got the following error: test sslv3 ERROR in SERVER 2212:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:.\ssl\s3_pkt.c:453: SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 512 bit RSA problems. Is this a problem on my end or an old test that is out of date? thanks. Michael Hunley Senior Engineer PocketPurchase, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
