Re: another Signal 11 (seg fault) in MD5_Init

[kjfw]

I don't know if the context is being reused.  I'm not calling these functions 
directly; I'm just using OpenSSL.  Here's some of the output from the crash:

Tue Jan 20 14:47:20 2004: SS: An unexpected exception has been detected in native code 
outside the VM.
Tue Jan 20 14:47:20 2004: SS: Unexpected Signal : 11 occurred at PC=0xE30C39CC
Tue Jan 20 14:47:20 2004: SS: Function=MD5_Init+0x4C
Tue Jan 20 14:47:20 2004: SS: Library=/opt/local/ssl/lib/libcrypto.so.0.9.7
Tue Jan 20 14:47:20 2004: SS:
Tue Jan 20 14:47:20 2004: SS: Current Java thread:
Tue Jan 20 14:47:20 2004: SS:at comm.iris.SSLUtil.SSLRead(Native Method)
Tue Jan 20 14:47:20 2004: SS:at 
comm.iris.SSLSocketChannel.readImpl(SSLSocketChannel.java:52)
Tue Jan 20 14:47:20 2004: SS:at 
comm.iris.FdSocketChannel.read(FdSocketChannel.java:158)


As you can see, OpenSSL is being called from Java via a native method.  In this case, 
the crash occurred during a call to SSL_read.

We have the same software running on staging:

System Configuration:  Sun Microsystems  sun4u Sun Enterprise 220R (2 X UltraSPARC-II 
450MHz)
System clock frequency: 113 MHz
Memory size: 1024 Megabytes


And QA:

System Configuration:  Sun Microsystems  sun4u Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 
440MHz)
System clock frequency: 110 MHz
Memory size: 1024 Megabytes


And a few other solaris-based stacks.  But we've only seen this problem on production. 
 We've also done some testing on Linux, but not over a long period of time.  

In regards to testing other versions of OpenSSL, we've used older versions on other 
stacks, but only 0.9.7b on production.  We will be moving to 0.9.7c soon.

Again, thanks for your help.

-- Kelly

> In message <[EMAIL PROTECTED]> on Tue, 20 Jan 2004 21:19:03 
> +, [EMAIL PROTECTED] said:
> 
> kjfw> I posted over a month ago about an "Unexpected Signal: 11" in
> kjfw> MD5_Init.  The same error has happened again, but this time I
> kjfw> have a bit more information:  MD5_Init was called with a null
> kjfw> pointer (c == 0), hence the seg fault.  However, no calls to
> kjfw> CRYPTO_malloc (or similar functions including OPENSSL_malloc
> kjfw> functions) failed, so this is not an out-of-memory problem.
> kjfw> Thus, given that we're using OpenSSL in non-blocking mode in a
> kjfw> multi-threaded environment and the extremely infrequent nature
> kjfw> of this bug, my best guess is that this is some very obscure
> kjfw> timing issue whereby MD5_Init is being called before the
> kjfw> relevant data structures have been fulling initialized.
> kjfw> 
> kjfw> So does anybody have any idea how this might happen?  Any
> kjfw> suggestions on how I might further track the problem down?  I'm
> kjfw> planning on adding some printfs to EVP_DigestInit_ex to print
> kjfw> some additional contextual info if ctx->digest->init is called
> kjfw> with ctx->md_data == null.
> 
> So, the context that's passed to EVP_DigestInit_ex(), is it reused?
> Have you cleaned up properly?
> 
> You see, the only reason I can see for MD5_init to be called with
> c == 0 is if ctx->digest (in EVP_DigestInit_ex()) is the same as
> type.
> 
> kjfw> Again, we've only seen this problem on our production stack:
> kjfw> 
> kjfw> OpenSSL 0.9.7b 10 Apr 2003
> 
> And what other versions have you tested with in similar environments?
> The answer to that might give us clues to what exactly happens...
> 
> -
> Please consider sponsoring my work on free software.
> See http://www.free.lp.se/sponsoring.html for details.
> You don't have to be rich, a $10 donation is appreciated!
> 
> -- 
> Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
> [EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
> 
> Unsolicited commercial email is subject to an archival fee of $400.
> See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Windows DLL naming inconsistency

[Martin Germann]

Hi,

I noticed an inconsistency in the windows library names: 

When compiling OpenSSL on windows with gcc (MinGW), the resulting ssl 
library is called 'libssl32.dll'. Using MS Visual C++ (and Borland C++, i 
suppose), the resulting binary will be called 'ssleay32.dll'.

This may cause a lot of confusion for users compiling OpenSSL on Win32. 
Therefore, I suggest to modify the targets for Visual C++ and Borland C++ 
to also build 'libssl32.dll', as this target name seems to be most widely 
used (e.g. stunnel).

Regards, Martin
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: another Signal 11 (seg fault) in MD5_Init

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 20 Jan 2004 21:19:03 +, [EMAIL PROTECTED] 
said:

kjfw> I posted over a month ago about an "Unexpected Signal: 11" in
kjfw> MD5_Init.  The same error has happened again, but this time I
kjfw> have a bit more information:  MD5_Init was called with a null
kjfw> pointer (c == 0), hence the seg fault.  However, no calls to
kjfw> CRYPTO_malloc (or similar functions including OPENSSL_malloc
kjfw> functions) failed, so this is not an out-of-memory problem.
kjfw> Thus, given that we're using OpenSSL in non-blocking mode in a
kjfw> multi-threaded environment and the extremely infrequent nature
kjfw> of this bug, my best guess is that this is some very obscure
kjfw> timing issue whereby MD5_Init is being called before the
kjfw> relevant data structures have been fulling initialized.
kjfw> 
kjfw> So does anybody have any idea how this might happen?  Any
kjfw> suggestions on how I might further track the problem down?  I'm
kjfw> planning on adding some printfs to EVP_DigestInit_ex to print
kjfw> some additional contextual info if ctx->digest->init is called
kjfw> with ctx->md_data == null.

So, the context that's passed to EVP_DigestInit_ex(), is it reused?
Have you cleaned up properly?

You see, the only reason I can see for MD5_init to be called with
c == 0 is if ctx->digest (in EVP_DigestInit_ex()) is the same as
type.

kjfw> Again, we've only seen this problem on our production stack:
kjfw> 
kjfw> OpenSSL 0.9.7b 10 Apr 2003

And what other versions have you tested with in similar environments?
The answer to that might give us clues to what exactly happens...

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

another Signal 11 (seg fault) in MD5_Init

[kjfw]

Hi all,

I posted over a month ago about an "Unexpected Signal: 11" in MD5_Init.  The same 
error has happened again, but this time I have a bit more information:  MD5_Init was 
called with a null pointer (c == 0), hence the seg fault.  However, no calls to 
CRYPTO_malloc (or similar functions including OPENSSL_malloc functions) failed, so 
this is not an out-of-memory problem.  Thus, given that we're using OpenSSL in 
non-blocking mode in a multi-threaded environment and the extremely infrequent nature 
of this bug, my best guess is that this is some very obscure timing issue whereby 
MD5_Init is being called before the relevant data structures have been fulling 
initialized.

So does anybody have any idea how this might happen?  Any suggestions on how I might 
further track the problem down?  I'm planning on adding some printfs to 
EVP_DigestInit_ex to print some additional contextual info if ctx->digest->init is 
called with ctx->md_data == null.

Again, we've only seen this problem on our production stack:

OpenSSL 0.9.7b 10 Apr 2003

SunOS tango 5.8 Generic_108528-17 sun4u sparc SUNW,Sun-Fire-280R

System Configuration:  Sun Microsystems  sun4u Sun Fire 280R (2 X UltraSPARC-III) 
System clock frequency: 150 MHz
Memory size: 2048 Megabytes


Any help would be greatly appreciated.

Thanks,
Kelly
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Ports from OpenSSL to SSLeay

[S.Mehdi Sheikhalishahi]

Hi All
 I develop a function (OpenSSL Compatible) that
generate hash value of messages.Now I want to port it
to SSLeay.


1 #include 
  2 #include 
  3 void gen_digest(char* digest_name,char*
input,unsigned char* digest,int* digest_len)
  4 {
  5 EVP_MD_CTX mdctx;
  6 const EVP_MD *md;
  7 char mess1[] = "Test Message\n";
  8 unsigned char
md_value[EVP_MAX_MD_SIZE];
  9 int md_len, i;
 10
 11 OpenSSL_add_all_digests();
 12
 13 strcpy(mess1,input);
 14
 15 md =
EVP_get_digestbyname(digest_name);
 16
 17 if(!md) {
 18printf("Unknown message digest
%s\n", digest_name);
 19exit(1);
 20 }
 21
 22 EVP_MD_CTX_init(&mdctx);
 23 EVP_DigestInit_ex(&mdctx, md, NULL);
 24 EVP_DigestUpdate(&mdctx, mess1,
strlen(mess1));
 25// EVP_DigestUpdate(&mdctx, mess2,
strlen(mess2));
 26 EVP_DigestFinal_ex(&mdctx, md_value,
&md_len);
 27 EVP_MD_CTX_cleanup(&mdctx);
 28 strcpy(digest,md_value);
 29 *digest_len=md_len;
 }
 31  main(int argc, char *argv[])
 32 {
 33 unsigned char
md_value[EVP_MAX_MD_SIZE];
 34 int md_len,i;
 35
 36 printf("Digest is: ");
 37
gen_digest("md5","Salam",md_value,&md_len);
 38 for(i = 0; i < md_len; i++)
printf("%02x", md_value[i]);
 39 printf("\n");
 40 }

Please Help me

__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]