Hi everyone.
Any idea on this error?
I have run Apache with SSL due to this issue.
Thanks,
Mon
From: monloi perez
To: openssl-users@openssl.org
Sent: Wed, July 6, 2011 8:11:22 PM
Subject: Segmentation Fault when restarting apache with ssl
Hi,
I'm new to t
hi
When I started to Linux in 2001 I found the event I could not recompile perl
error and corruption
Le mercredi 6 juillet 2011 14:11, monloi perez a écrit :
> Hi,
>
>
> I'm new to the list and having this issue.
>
> I installed apache + openssl. When i started apache I get an error
> "Segment
On Thu, Oct 1, 2009 at 6:07 PM, Dwight Schauer wrote:
> We are using openssl-32bit-0.9.8a-18.26 on SLES 10.2 (x86_64).
>
> This problem is only occurring on a very small percentage of our installs,
> and is not readily repeatable, but is always results in the same back trace.
>
> Program terminat
Alright, a little more information.
I took the example cli/serv ssl source from the openssl distribution and messed
it up so that SSL_read would segfault in the serv executable.
Compiled and ran the resulting pair and got a core file and examined it.
On an up to date Arch linux install the back
Controlla gli indirizzi di memoria relativi ai parametri della funzione ...
On Wed, Sep 30, 2009 at 4:18 PM, marina russo wrote:
> Hi!
> I'm trying to run a client server application using openssl library,but
> i've got some problems because, when i use the method: SSLv3_client_method()
> i h
Did you check that you actually support SSLv3_client_method()?
On Wed, September 30, 2009 10:18 am, marina russo wrote:
>
> Hi!
> I'm trying to run a client server application using openssl library,but
> i've got some problems because, when i use the method:
> SSLv3_client_method() i have a segment
c Ion
- Original Message
From: Kyle Hamilton <[EMAIL PROTECTED]>
To: openssl-users@openssl.org
Sent: Friday, April 18, 2008 5:32:49 PM
Subject: Re: Segmentation fault in SSL_read() (Re-post)
ergh. My apologies for not catching that. You're right, it shouldn't
matter on t
ergh. My apologies for not catching that. You're right, it shouldn't
matter on the client side.
Okay... going back to basics (I'm sorry if this seems a bit
patronizing, I honestly don't intend it to be such), a segfault occurs
on a pointer dereference, trying to gain access to memory which is
i
From: Kyle Hamilton <[EMAIL PROTECTED]>
To: openssl-users@openssl.org
Sent: Friday, April 18, 2008 2:33:03 PM
Subject: Re: Segmentation fault in SSL_read() (Re-post)
How are you creating an MFC executable on Linux?
-Kyle H
On Fri, Apr 18, 2008 at 4:29 AM, Ion Scerbatiuc <[EMAIL PROTECTED]
ds,
> Scerbatiuc Ion
>
>
> - Original Message
> From: Kyle Hamilton <[EMAIL PROTECTED]>
> To: openssl-users@openssl.org
>
> Sent: Friday, April 18, 2008 2:14:03 PM
> Subject: Re: Segmentation fault in SSL_read() (Re-post)
>
> My initial idea would be that
questions?
Thanks for your time!
Regards,
Scerbatiuc Ion
- Original Message
From: Kyle Hamilton <[EMAIL PROTECTED]>
To: openssl-users@openssl.org
Sent: Friday, April 18, 2008 2:14:03 PM
Subject: Re: Segmentation fault in SSL_read() (Re-post)
My initial idea would be that you're
My initial idea would be that you're passing in an invalid pointer to
SSL_read. Does this happen with, say, openssl s_client?
Remember a couple of things:
1) You MUST use the proper version of the library (debug or release)
with the appropriate build setting in your project (debug or release).
2
Sorry again. I copied the dump from another core file and the disass was from
another:
The dump for that diisassembly snippet was:
#0 0x00c9b770 in SSL_read () from /lib/libssl.so.4
(gdb) bt
#0 0x00c9b770 in SSL_read () from /lib/libssl.so.4
#1 0x0805b27f in wns::ServerPort::pending (this=0x93
Hi,
I had a re- look into the segmentation fault issue in my application. What I
observe is that OPENSSL_malloc returns NULL in the 'int EVP_DigestInit_ex'
function in digest.c:
if (ctx->digest != type)
{
if (ctx->digest && ctx->digest->ctx_size)
OPENSSL_free(ctx->md_data
SHA_CTX *c is getting corrupted. GDB indicated ctx=0x0 in init(). However
it was not the case.
static int init(EVP_MD_CTX *ctx)
{
if(ctx != 0L)
{
return SHA1_Init(ctx->md_data);
}
else
{
printf("ctx is NULL\n"); //Never to be seen thou
At times The following traces as well are obtained:
(gdb) bt
#0 MD5_Init (c=0x0) at md5_dgst.c:75
#1 0x405b2a90 in init (ctx=0x0) at m_md5.c:73
#2 0x405afc91 in EVP_DigestInit_ex (ctx=0x8e29b44, type=0x4061f560,
impl=0x0) at digest.c:207
#3 0x403819f5 in ssl3_init_finished_mac (s=0x8e298c8) a
David,
The OpenSSL version that I use is openssl-0.9.8e. Your guess about methods
being called is right. It appears to be stack corruption.
Gayathri,
I don't suspect the gdb. I checked the CTX status in HASH_INIT (SHA_CTX *c)
under stress , 'c' was indeed NULL and the application immediately d
The stack trace showing a null sha1 transform kindof caught my attention
here, I wouldnt go by the the GDB call trace coz its obviously a memory
leak and the gdb stack could have been corrupted, many a times I see 0x0
in the frames but when you actually try to print the ctx address it would
be
> Even reducing the thread stack size didn't help.
> I observe that the thread creation as such is not
> a problem. I create about 1000 threads , delay in
> each thread the SSL_connect for about 10 sec.
> Once the delay expires and each client make connections
> to the server the seg fault occurs.
Even reducing the thread stack size didn't help. I observe that the thread
creation as such is not a problem. I create about 1000 threads , delay in
each thread the SSL_connect for about 10 sec.
Once the delay expires and each client make connections to the server the
seg fault occurs.
Regards,
Pr
> > This is really one of those "don't do that then" things.
> > Thread-per-connection is well-known to break down at about 750
> > connections.
> Just curious at how the number 750 was calculated or deduced. And
> is this a linux-specific limit?
On Windows, it's usually more like 800 on older v
--- David Schwartz <[EMAIL PROTECTED]> wrote:
>
> This is really one of those "don't do that then" things.
> Thread-per-connection is well-known to break down at about 750 connections.
>
[snip]
>
> It may help to reduce the stack size for each thread. But you really should
> re-architect. Thread
On 10/16/07, Prabhu S <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> Yes, the design of one thread per connection is bit odd. Our application is
> used to test a SSL server for its performance. The application would simulate
> hundreds of client and at a time try connecting to the server. The server
Hi David,
Yes, the design of one thread per connection is bit odd. Our application is
used to test a SSL server for its performance. The application would
simulate hundreds of client and at a time try connecting to the server. The
server would be thus tested for burst connection handling capabilit
Hi Gayathri,
I couldn't entirely grasp what you had mentioned. l didn't find sha1 in
lsmod command output.
If you could describe briefly the issue you had experienced that would be
very much helpful.
Thanks & Regards,
Prabhu. S
On 10/15/07, Gayathri S <[EMAIL PROTECTED]> wrote:
>
> Hi Prabhu,
>
> The application creates about 800 threads in a Linux 2.6 Kernel.
This is really one of those "don't do that then" things.
Thread-per-connection is well-known to break down at about 750 connections.
> #0 SHA1_Init (c=0x0) at sha_locl.h:150
> #1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
> #
Hi Prabhu,
Can you check the sha1 usage count in the lsmod?
I am thinking you have not freed the sha tfm and eventually run out of it.
I hit a similar issue when making use of linux sha1.
Thanks
--Gayathri
On Mon, 15 Oct 2007, Prabhu S wrote:
Hi,
The SSL enabled client application seg faults
Solved adding
SSL_library_init ();
thanks
Marek Marcola ha scritto:
Hello,
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8321)]
0x4003f866 in SSL_CTX_load_verify_locations () from /usr/lib/libssl.so.0
Here is the code :
#define CIPHER_L
CTX is NULL as you say!
-> (null)
Now say :
8423:error:140A90A1:SSL routines:SSL_CTX_new:library has no
ciphers:ssl_lib.c:1366:
Thanks
Marek Marcola ha scritto:
Hello,
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8321)]
0x4003f866 in S
Hello,
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 8321)]
> 0x4003f866 in SSL_CTX_load_verify_locations () from /usr/lib/libssl.so.0
>
>
>
> Here is the code :
>
>
> #define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
> #define CAFILE "/home/ken
On Mon, Mar 07, 2005, T. Quirin wrote:
> Hi,
> thank you Steve my verification function works now. But I want to check
> the RSA key before I use it. If I run "if(RSA_check_key(r) != 1) return
> -5;" I get a "Segmentation fault ". It works without this line.
>
>
RSA_check_key() will only chec
Scialino Marco wrote:
Hi,
I hope someone can give me help on this.
After installing perl, openssl and Crypt::SSLeay I built a simple perl
program to connect to a web server that has *only* Transport Layer
Protocol (TLS V1) enabled, but I get a segmentation fault.
The same program has no problem
On Monday 11 August 2003 21:31, Mateus wrote:
> Hi,
>
> I'm trying to use the function BN_bn2bin to convert a big number
> and I had a segmentation fault inside of it.
> I have already tried to debug my source and I'm almost shure that
> it's ok because it is very simple.
> Would
On Mon, 11 Aug 2003, Mateus wrote:
> I'm trying to use the function BN_bn2bin to convert a big number and I
> had a segmentation fault inside of it.
Is the to area allocated and big enough to fit the number?
Is the BIGNUM ok? Try printing it with BN_print_fp.
Have you perhaps stomped on some ot
34 matches
Mail list logo
