Skip Menu |
 

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 75841
Status: resolved
Worked: 13.3 hours (800 min)
Priority: 0/
Queue: Net-SSLeay

People
Owner: MIKEM [...] cpan.org
Requestors: carnil [...] debian.org
Cc: kmx [...] cpan.org
info [...] maximka.de
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



From: CARNIL [...] cpan.org
Subject: libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Download (untitled) / with headers
text/plain 1.5k
Hi This bug has been forwarded from http://bugs.debian.org/661566 Package: libnet-ssleay-perl Version: 1.45-1 Severity: important Apache segfaults when this module is included in a mod_perl application and mod_ssl is enabled. I am using the prefork MPM. To reproduce: a2enmod ssl a2enmod perl echo "PerlModule Net::SSLeay" >/etc/apache2/conf.d/sslbug.conf service apache2 restart 1.43-1 is also broken in this regard. 1.42-1+b1 works. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libnet-ssleay-perl depends on: ii libc6 2.13-26 ii libssl1.0.0 1.0.0g-1 ii perl 5.14.2-7 ii perl-base [perlapi-5.14.2] 5.14.2-7 libnet-ssleay-perl recommends no packages. Versions of packages libnet-ssleay-perl suggests: ii perl [libmime-base64-perl] 5.14.2-7 -- no debconf information -- _ivan This was easily reproducible for me installing on a Debian sid system apache2-mpm-prefork, libapache2-mod-perl2 and libnet-ssleay-perl (in Version 1.45). Then echo "PerlModule Net::SSLeay" >/etc/apache2/conf.d/sslbug.conf Restarting now apache2, let it segfault. Niko Tyni has posted some more information on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661566#26 Thanks in advance, Salvatore Bonaccorso, Debian Perl Group
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Sun, 18 Mar 2012 16:49:51 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 3.3k
kmx, are you listening in on this one? It appears that in the tst situation described below, the CLONE(...) and END(...) functions are called multiple times during web server startup. Your END code calls MUTEX_DESTROY(&LIB_init_mutex); and openssl_threads_cleanup(); And I dont think thats right. If END is called at the end of a thread as opposed to the end of the nterpreter (is that when its called? couldnt find any clear doc on that), I dont think LIB_init_mutex should be destroyed then. Further, openssl_threads_cleanup has code like this: if (!GLOBAL_openssl_mutex) return; ..... Safefree(GLOBAL_openssl_mutex); and nothing ion the code ever clears GLOBAL_openssl_mutex. so if it is called multiple times, Safefree(GLOBAL_openssl_mutex) will be called multiple times, and that is the cause of the crash reported below. So, perhaps the END function is not required at all? And openssl_threads_cleanup should protect itself against multiple calls? And openssl_threads_cleanup should only be called when the whole interpreter exits (how can we catch that?) Cheers. On Saturday, March 17, 2012 07:46:05 AM you wrote: Show quoted text
> Sat Mar 17 07:46:03 2012: Request 75841 was acted upon. > Transaction: Ticket created by CARNIL > Queue: Net-SSLeay > Subject: libnet-ssleay-perl: Segfault when lniked into an > Apache/mod_ssl/mod_perl process > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: carnil@debian.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > Hi > > This bug has been forwarded from http://bugs.debian.org/661566 > > Package: libnet-ssleay-perl > Version: 1.45-1 > Severity: important > > Apache segfaults when this module is included in a mod_perl application and > mod_ssl is enabled. I am using the prefork MPM. > > To reproduce: > a2enmod ssl > a2enmod perl > echo "PerlModule Net::SSLeay" >/etc/apache2/conf.d/sslbug.conf > service apache2 restart > > 1.43-1 is also broken in this regard. > 1.42-1+b1 works. > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages libnet-ssleay-perl depends on: > ii libc6 2.13-26 > ii libssl1.0.0 1.0.0g-1 > ii perl 5.14.2-7 > ii perl-base [perlapi-5.14.2] 5.14.2-7 > > libnet-ssleay-perl recommends no packages. > > Versions of packages libnet-ssleay-perl suggests: > ii perl [libmime-base64-perl] 5.14.2-7 > > -- no debconf information
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Show quoted text
> kmx, are you listening in on this one?

Yes I have added myself to cc:

Show quoted text
> It appears that in the tst situation described below, the
> CLONE(...) and END(...) functions are called multiple times
> during web server startup.

Multiple calls of CLONE() of IMHO OK (it is called for every new thread) and should not cause a crash, however multiple calls to END() should not happen - and as far as I have tested (I really spend some time on this) the END() is called only once when perl interpret is finished (with one exception related to perl's fork() emulation on MS Windows platform - but we have a workaround for this).

Anyhow, I do not a reason why END(...) should be called at webserver startup (I expect it to be called at shutdown)

See http://perldoc.perl.org/perlmod.html - quote:

"An END code block is executed as late as possible, that is, after perl has finished running the program and just before the interpreter is being exited, even if it is exiting as a result of a die() function."


Show quoted text
> ...
>
> Further,
> openssl_threads_cleanup
> has code like this:
>
> if (!GLOBAL_openssl_mutex) return;
> .....
> Safefree(GLOBAL_openssl_mutex);
>
> and nothing ion the code ever clears GLOBAL_openssl_mutex.
>
> so if it is called multiple times, Safefree(GLOBAL_openssl_mutex)
> will be called multiple times, and that is the cause of the crash
> reported below.

Well, to play safe we can add after each Safefree a line like this:

Safefree(any_pointer);
any_pointer = NULL;

It should go to 2 places where we call Safefree(...):
- openssl_dynlocking_destroy_function()
- openssl_threads_cleanup()
(IMHO you can add&commit this as it make things only better)

But in my opinion it is not the core of the problem.

Show quoted text
> So, perhaps the END function is not required at all?

I do not thik so, maybe the END() is not the best place but we should call openssl_threads_cleanup somewhere.

Show quoted text
> And openssl_threads_cleanup should protect itself against multiple
> calls?

Yes this is correct.

Show quoted text
> And openssl_threads_cleanup should only be called when the whole
> interpreter exits (how can we catch that?)

Yes this is correct, normally using END() should assure that we call it just once just before perl interpreter is being exited.

However there are some gotchas connected to mod_perl mode of operation.

Here is my theory (I have not Linux+Apache+mod_perl+mod_ssl+net-ssleay enviroment to test it right now):

1/ The biggest problem is that we have double openssl initialization issue
- one from Apache's mod_ssl - see httpd-2.2.22\modules\ssl\ssl_util.c - functions ssl_util_thread_setup/ssl_util_thread_cleanup
- the second from Net::SSleay

I am not sure what initialization happes first but I guess that mod_ssl is loaded before mod_perl+net-ssleay.

Double initialization is an issue with:
- multitreading related stuff
- multiple "SSLeay_add_ssl_algorithms()" calls (you perhaps remember that one)

I think this is the reason why it crashes - simmply:
- mod_ssl initializes openssl library (with all thread related mutexes and callbacks)
- Net::SSLeay does openssl initialization in its way again
- this should inevitably crash

2/ I am not an expert on mod_perl but according to http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support it is hard to guess how Apache with threaded MPMs works with Net::SSLeay.

According to link above it seems that each Apache thread creates it own perl interpret within the same Apache process. I am not sure what exactly happens when you load Net::SSleay into it.

Current Net::SSLeay implementation is ready for scenario like this:
a/ perl starts (as a new process)
b/ via "use Net::SSLeay" (with one perl interpret is running) we invoke BOOT: section of SSLeay.sx
c/ Boot: section calls openssl_threads_init()
d/ shortly after "use Net::SSLeay" we usually call "SSLeay_add_ssl_algorithms()"
e/ later in the perl code we create some new threads via "threads->new(\&do_the_job)"

Whereas mod_perl scenario is IMHO something like this (not sure about the order)
a/ Apache starts (as a new process)
b/ Apache loads mod_ssl module (which does all necessary openssl initialization)
c/ Apache creates a couple of MPM threads + starts couple of perl interprets
d/ Then you try to load Net::SSleay
e/ Net::SSleay is not aware about the fact that openssl library was already initialized and call initialization again
f/ Note that at this point we have multiple perl interprets - I am not sure how many times Net::SSLeay's BOOT: section is gonna be called
g/ An you are right as there are multiple perl interprets the END(...) section is called for each perl interpret (but it should happen IMHO at Apache shutdown)

My conclusion:

1/ If we can somehow detect that thread related setup of openssl lib was already done we can simply skip our initialization

2/ As mod_ssl calls itself SSL_library_init() which is an alias for "SSLeay_add_ssl_algorithms()" I am not sure what happens when you call it again from perl via Net::SSLeay::SSL_library_init() - I expect a crash


--
kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 19 Mar 2012 19:50:32 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 7.6k
Hi, On Monday, March 19, 2012 05:31:42 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > >
> > kmx, are you listening in on this one?
> > Yes I have added myself to cc:
Thanks! Value your feedback. Show quoted text
> > It appears that in the tst situation described below, the > > CLONE(...) and END(...) functions are called multiple times > > during web server startup.
> > Multiple calls of CLONE() of IMHO OK (it is called for every new thread) and > should not cause a crash, however multiple calls to END() should not happen > - and as far as I have tested (I really spend some time on this) the END() > is called only once when perl interpret is finished (with one exception > related to perl's fork() emulation on MS Windows platform - but we have a > workaround for this).
Yes, I saw that. But, according to http://perldoc.perl.org/threads.html "These END blocks will then be executed when the thread's interpreter is destroyed (i.e., either during a ->join() call, or at program termination)." I havent been able to generate double END calls in my simple sample code, but I have proved that Apach2 mod_perl certainly does call END multiple times Show quoted text
> > Anyhow, I do not a reason why END(...) should be called at webserver startup > (I expect it to be called at shutdown) > > See http://perldoc.perl.org/perlmod.html - quote: > > "An END code block is executed as late as possible, that is, after perl has > finished running the program and just before the interpreter is being > exited, even if it is exiting as a result of a die() function." >
> > ... > > > > Further, > > openssl_threads_cleanup > > has code like this: > > > > if (!GLOBAL_openssl_mutex) return; > > ..... > > Safefree(GLOBAL_openssl_mutex); > > > > and nothing ion the code ever clears GLOBAL_openssl_mutex. > > > > so if it is called multiple times, Safefree(GLOBAL_openssl_mutex) > > will be called multiple times, and that is the cause of the crash > > reported below.
> > Well, to play safe we can add after each Safefree a line like this: > > Safefree(any_pointer); > any_pointer = NULL; > > It should go to 2 places where we call Safefree(...): > - openssl_dynlocking_destroy_function() > - openssl_threads_cleanup() > (IMHO you can add&commit this as it make things only better) > > But in my opinion it is not the core of the problem.
I agree. I think if there can be (and there are) multiple calls to END within a process, then we need to make sure that END is not really the end of Net::SSLeay. If it can be called multiple times within a single process, even during startup, then it should not call MUTEX_DESTROY(&LIB_init_mutex); and it should not call openssl_threads_cleanup(); Therefore, I dont think we should have END at all. Then, you might ask, how will openssl_threads_cleanup() get called? I cant see a way to call it "just before the process (as opposed to a thread) really exits". But what would be the problem if we did not call it? A little leak that is only evident at exit time? There would not be a per-thread leak, and there are no per-thread resources that we need to free. Show quoted text
>
> > So, perhaps the END function is not required at all?
> > I do not thik so, maybe the END() is not the best place but we should call > openssl_threads_cleanup somewhere. >
> > And openssl_threads_cleanup should protect itself against multiple > > calls?
> > Yes this is correct. >
> > And openssl_threads_cleanup should only be called when the whole > > interpreter exits (how can we catch that?)
> > Yes this is correct, normally using END() should assure that we call it just > once just before perl interpreter is being exited.
I used to think so too, but based on the above I now know and have observed that not to be the case. Show quoted text
> > However there are some gotchas connected to mod_perl mode of operation. > > Here is my theory (I have not Linux+Apache+mod_perl+mod_ssl+net-ssleay > enviroment to test it right now): > > 1/ The biggest problem is that we have double openssl initialization issue > - one from Apache's mod_ssl - see httpd-2.2.22\modules\ssl\ssl_util.c - > functions ssl_util_thread_setup/ssl_util_thread_cleanup > - the second from Net::SSleay > > I am not sure what initialization happes first but I guess that mod_ssl is > loaded before mod_perl+net-ssleay. > > Double initialization is an issue with: > - multitreading related stuff > - multiple "SSLeay_add_ssl_algorithms()" calls (you perhaps remember that > one)
but only when called simultaneously by 2 threads, I think. Show quoted text
> > I think this is the reason why it crashes - simmply: > - mod_ssl initializes openssl library (with all thread related mutexes and > callbacks) > - Net::SSLeay does openssl initialization in its way again > - this should inevitably crash
Disagree, the immediate cause of the crash is double free of GLOBAL_openssl_mutex in openssl_threads_init I have proved that is what happens, and that if I comment out the Safefree(GLOBAL_openssl_mutex); it does not crash. Show quoted text
> > 2/ I am not an expert on mod_perl but according to > http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support it > is hard to guess how Apache with threaded MPMs works with Net::SSLeay. > > According to link above it seems that each Apache thread creates it own perl > interpret within the same Apache process. I am not sure what exactly > happens when you load Net::SSleay into it. > > Current Net::SSLeay implementation is ready for scenario like this: > a/ perl starts (as a new process) > b/ via "use Net::SSLeay" (with one perl interpret is running) we invoke > BOOT: section of SSLeay.sx > c/ Boot: section calls openssl_threads_init() > d/ shortly after "use Net::SSLeay" we usually call > "SSLeay_add_ssl_algorithms()" > e/ later in the perl code we create some new threads via > "threads->new(\&do_the_job)" > > Whereas mod_perl scenario is IMHO something like this (not sure about the > order) > a/ Apache starts (as a new process) > b/ Apache loads mod_ssl module (which does all necessary openssl > initialization) > c/ Apache creates a couple of MPM threads + starts couple of perl interprets > d/ Then you try to load Net::SSleay > e/ Net::SSleay is not aware about the fact that openssl library was already > initialized and call initialization again > f/ Note that at this point we have multiple perl interprets - I am not sure > how many times Net::SSLeay's BOOT: section is gonna be called > g/ An you are right as there are multiple perl interprets the END(...) > section is called for each perl interpret (but it should happen IMHO at > Apache shutdown) > > My conclusion: > > 1/ If we can somehow detect that thread related setup of openssl lib was > already done we can simply skip our initialization
I dont believe that is possible, and in any case would not solve the crash we are seeing now. Show quoted text
> > 2/ As mod_ssl calls itself SSL_library_init() which is an alias for > "SSLeay_add_ssl_algorithms()" I am not sure what happens when you call it > again from perl via Net::SSLeay::SSL_library_init() - I expect a crash
I think we should remove END and openssl_threads_cleanup() Show quoted text
> > > -- > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 19 Mar 2012 11:48:00 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 5.1k
Show quoted text
>>> It appears that in the tst situation described below, the >>> CLONE(...) and END(...) functions are called multiple times >>> during web server startup. >>>
>> Multiple calls of CLONE() of IMHO OK (it is called for every new thread) and >> should not cause a crash, however multiple calls to END() should not happen >> - and as far as I have tested (I really spend some time on this) the END() >> is called only once when perl interpret is finished (with one exception >> related to perl's fork() emulation on MS Windows platform - but we have a >> workaround for this). >>
> Yes, I saw that. > > But, according to > > http://perldoc.perl.org/threads.html > > "These END blocks will then be executed when the thread's interpreter is > destroyed (i.e., either during a ->join() call, or at program termination)." > > I havent been able to generate double END calls in my simple sample code, but > I have proved that Apach2 mod_perl certainly does call END multiple times >
Hmm, I am starting to feel that you are right, END(...) is probably not gonna do correctly what we need to be done. Although I still do not understand that during _startup_ the _END_ is called (but it not important at the moment). Show quoted text
>>> ... >>> >>> Further, >>> openssl_threads_cleanup >>> has code like this: >>> >>> if (!GLOBAL_openssl_mutex) return; >>> ..... >>> Safefree(GLOBAL_openssl_mutex); >>> >>> and nothing ion the code ever clears GLOBAL_openssl_mutex. >>> >>> so if it is called multiple times, Safefree(GLOBAL_openssl_mutex) >>> will be called multiple times, and that is the cause of the crash >>> reported below. >>>
>> Well, to play safe we can add after each Safefree a line like this: >> >> Safefree(any_pointer); >> any_pointer = NULL; >> >> It should go to 2 places where we call Safefree(...): >> - openssl_dynlocking_destroy_function() >> - openssl_threads_cleanup() >> (IMHO you can add&commit this as it make things only better) >> >> But in my opinion it is not the core of the problem. >>
> I agree. I think if there can be (and there are) multiple calls to END within > a process, then we need to make sure that END is not really the end of > Net::SSLeay. If it can be called multiple times within a single process, even > during startup, then it should not call > > MUTEX_DESTROY(&LIB_init_mutex); > > and it should not call openssl_threads_cleanup(); > > Therefore, I dont think we should have END at all. > Then, you might ask, how will openssl_threads_cleanup() get called? I cant see > a way to call it "just before the process (as opposed to a thread) really > exits". But what would be the problem if we did not call it? A little leak > that is only evident at exit time? There would not be a per-thread leak, and > there are no per-thread resources that we need to free. >
Definitely a call to MUTEX_DESTROY(&LIB_init_mutex); inside END() is currently not ready to handle multiple calls. Commenting out all we have now inside END(...) can probably be the easiest way to fix this. There are no significant leaks we should be worried about - we are only leaving openssl library in an unstable state as it might have some callbacks/mutexes pointed to a memory location(s) that will go away. Or we can (just idea not insisting on that) do a similar thing to Win32 END() workaround - which means to allow to destroy/clean openssl threading only to the thread that has done the initialization (check for GLOBAL_openssl_mutex_creator variable in SSLeay.xs). Show quoted text
>> I think this is the reason why it crashes - simmply: >> - mod_ssl initializes openssl library (with all thread related mutexes and >> callbacks) >> - Net::SSLeay does openssl initialization in its way again >> - this should inevitably crash >>
> Disagree, the immediate cause of the crash is double free of > GLOBAL_openssl_mutex in openssl_threads_init > I have proved that is what happens, and that if I comment out the > Safefree(GLOBAL_openssl_mutex); > it does not crash. >
You are right (assuming that you mean openssl_threads_cleanup not openssl_threads_init), maybe adding GLOBAL_openssl_mutex = NULL; after Safefree(GLOBAL_openssl_mutex) could also work Show quoted text
>> 1/ If we can somehow detect that thread related setup of openssl lib was >> already done we can simply skip our initialization >>
> I dont believe that is possible, and in any case would not solve the crash we > are seeing now. >
Yes, it is not related to the END-crash discussed above but it seems to be possible as CRYPTO_get_locking_callback() exists My summary: 1/ Safefree(GLOBAL_openssl_mutex) in openssl_threads_cleanup should be followed by GLOBAL_openssl_mutex = NULL; 2/ the way we (well I put that in) call MUTEX_DESTROY(&LIB_init_mutex); in END is buggy (quick&dirty fix is to comment out MUTEX_DESTROY() from END) 3/ the multiple END() call prevention is currently implemented only for Win32 (search for GLOBAL_openssl_mutex_creator) - we can implement this also for pthreads or again quick&dirty fix is to comment out openssl_threads_cleanup() from END In other words removing END() completely will fix all of 1/, 2/, 3/ 4/ We can try to add some kind of detection whether openssl library has already setup threading stuff or not (via CRYPTO_get_locking_callback & co.) -- kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 19 Mar 2012 13:50:49 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 656b
check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it is the best way to go. But to be honest it is starting to become overcomplicated - so perhaps simply removing END() + adding simple test for "already initialized threading" in openssl_threads_init() would be enough. It would really help me if you could put some debug warnings into a/ BOOT: section b/ END() c/ CLONE() and start apache+mod_perl+mod_ssl+net-ssleay e.g. warn("inside BOOT pthread=%p deinit=%d\n", pthread_self(), openssl_locking_should_be_deinitialized); Just to have some idea about the order how perl interprets are loaded/cloned/ended under mod_perl -- kmx

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 19 Mar 2012 14:30:31 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 272b
Show quoted text
> warn("inside BOOT pthread=%p deinit=%d\n", pthread_self(), openssl_locking_should_be_deinitialized); >
or better: warn("inside BOOT tid=%d myperl=%p pthread=%p deinit=%d\n", get_my_thread_id(), my_perl, pthread_self(), openssl_locking_should_be_deinitialized);
Download (untitled) / with headers
text/plain 964b
Hi, Show quoted text
> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it > is the best way to go.
I got segfault on new installed wheezy, apache2-mpm-worker 2.2.22-2 with patched r316 too. regards, palik On Mon Mar 19 08:51:01 2012, kmx@volny.cz wrote: Show quoted text
> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it > is the best way to go. > > But to be honest it is starting to become overcomplicated - so perhaps > simply removing END() + adding simple test for "already initialized > threading" in openssl_threads_init() would be enough. > > It would really help me if you could put some debug warnings into > a/ BOOT: section > b/ END() > c/ CLONE() > and start apache+mod_perl+mod_ssl+net-ssleay > > e.g. > warn("inside BOOT pthread=%p deinit=%d\n", pthread_self(), > openssl_locking_should_be_deinitialized); > > Just to have some idea about the order how perl interprets are > loaded/cloned/ended under mod_perl > > -- > kmx
CC: carnil [...] debian.org, kmx [...] cpan.org
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 19 Mar 2012 20:30:08 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 352b
Show quoted text
>> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it >> is the best way to go. >>
> I got segfault on new installed wheezy, apache2-mpm-worker 2.2.22-2 > with patched r316 too. >
OK, let's try Mike's "no-END/no-cleanup" approach. palik, could you please test enclosed threading_no_cleanup_r316.diff ? Thanks. -- kmx

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 648b
Hello All, We have now posted an update to net-ssleay svn, commit 318 that should fix this problem. If the OP and another can please confirm this fixes the reported crash, we will release a new dist. Cheers. On Mon Mar 19 15:30:24 2012, kmx@volny.cz wrote: Show quoted text
>
> >> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it > >> is the best way to go. > >>
> > I got segfault on new installed wheezy, apache2-mpm-worker 2.2.22-2 > > with patched r316 too. > >
> > OK, let's try Mike's "no-END/no-cleanup" approach. > > palik, could you please test enclosed threading_no_cleanup_r316.diff ? > > Thanks. > > -- > kmx
CC: kmx [...] cpan.org
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 07:36:32 +0100
To: MIKEM via RT <bug-Net-SSLeay [...] rt.cpan.org>
From: Salvatore Bonaccorso <carnil [...] debian.org>
Download (untitled) / with headers
text/plain 482b
Hey On Tue, Mar 20, 2012 at 06:26:53PM -0400, MIKEM via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Hello All, > > We have now posted an update to net-ssleay svn, commit 318 that should > fix this problem. > > If the OP and another can please confirm this fixes the reported crash, > we will release a new dist.
I'm not sure if I find time today, but I will try to check this today! Many thanks for your fast reaction on that! Regards, Salvatore
Download signature.asc
application/pgp-signature 836b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 840b
Hi, the module in r318 or current r321 enforce still segfault on apache start. palik On Tue Mar 20 18:26:52 2012, MIKEM wrote: Show quoted text
> Hello All, > > We have now posted an update to net-ssleay svn, commit 318 that should > fix this problem. > > If the OP and another can please confirm this fixes the reported crash, > we will release a new dist. > > Cheers. > > > On Mon Mar 19 15:30:24 2012, kmx@volny.cz wrote:
> >
> > >> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it > > >> is the best way to go. > > >>
> > > I got segfault on new installed wheezy, apache2-mpm-worker 2.2.22-2 > > > with patched r316 too. > > >
> > > > OK, let's try Mike's "no-END/no-cleanup" approach. > > > > palik, could you please test enclosed threading_no_cleanup_r316.diff ? > > > > Thanks. > > > > -- > > kmx
> >
Download (untitled) / with headers
text/plain 634b
Show quoted text
> palik, could you please test enclosed threading_no_cleanup_r316.diff ?
my response is surely to late, but I've tested r316 with threading_no_cleanup_r316.diff patch and got again segfault. palik On Mon Mar 19 15:30:24 2012, kmx@volny.cz wrote: Show quoted text
>
> >> check threading_fix_UNTESTED_r316.diff - just an idea, not sure if it > >> is the best way to go. > >>
> > I got segfault on new installed wheezy, apache2-mpm-worker 2.2.22-2 > > with patched r316 too. > >
> > OK, let's try Mike's "no-END/no-cleanup" approach. > > palik, could you please test enclosed threading_no_cleanup_r316.diff ? > > Thanks. > > -- > kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 09:44:55 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 202b
Show quoted text
> the module in r318 or current r321 enforce still segfault on apache start. >
Could you please try to comment out the line with "openssl_threads_init();" in BOOT section and try again? -- kmx
Download (untitled) / with headers
text/plain 155b
Show quoted text
> Could you please try to comment out the line with > "openssl_threads_init();" in BOOT section and try again?
apache start produced no segfault. palik
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 10:19:30 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 303b
Show quoted text
> apache start produced no segfault. >
Could you please revert back to rev321 + apply enclosed patch Then run: 1/ with openssl_threads_init(); in BOOT section 2/ without openssl_threads_init(); in BOOT section And could you please post more details about your Apache+mod_perl+... setup? -- kmx

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 516b
Show quoted text
> 1/ with openssl_threads_init(); in BOOT section
# service apache2 start Starting web server: apache2DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=0 Segmentation fault Action 'start' failed. The Apache error log may have more information. failed! Show quoted text
> 2/ without openssl_threads_init(); in BOOT section
# service apache2 start Starting web server: apache2DEBUG: BOOT start DEBUG: BOOT done: tid=0 my_perl=0 palik
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 10:42:41 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 778b
Show quoted text
>> 1/ with openssl_threads_init(); in BOOT section >>
> # service apache2 start > Starting web server: apache2DEBUG: BOOT start > DEBUG: init - begin > DEBUG: setting static locking > DEBUG: setting dynamic locking > DEBUG: init - end > DEBUG: BOOT done: tid=0 my_perl=0 > Segmentation fault > Action 'start' failed. > The Apache error log may have more information. > failed! >
I would also expect some "DEBUG: CLONE..." messages. Do you have mod_ssl loaded or not? To sort out whether static/dymanic locking is the problem - could you please: 1/ keep openssl_threads_init(); in BOOT section 2/ comment out these 3 lines CRYPTO_set_dynlock_create_callback CRYPTO_set_dynlock_lock_callback CRYPTO_set_dynlock_destroy_callback -- kmx
Download (untitled) / with headers
text/plain 1.4k
Show quoted text
> I would also expect some "DEBUG: CLONE..." messages.
My previous message contains complete STRERR-messages. Show quoted text
> Do you have mod_ssl loaded or not?
yes Show quoted text
> To sort out whether static/dymanic locking is the problem - could you > please: > 1/ keep openssl_threads_init(); in BOOT section
Restored 'SSLeay.xs' At revision 321. patch SSLeay.xs ../../debug_messages_r321.diff ... # service apache2 start Starting web server: apache2DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=0 Segmentation fault Action 'start' failed. The Apache error log may have more information. failed! Show quoted text
> 2/ comment out these 3 lines > CRYPTO_set_dynlock_create_callback > CRYPTO_set_dynlock_lock_callback > CRYPTO_set_dynlock_destroy_callback
# grep -A2 CRYPTO_set_dynlock_create_callback SSLeay.xs /* CRYPTO_set_dynlock_create_callback(openssl_dynlocking_create_function); CRYPTO_set_dynlock_lock_callback(openssl_dynlocking_lock_function); CRYPTO_set_dynlock_destroy_callback(openssl_dynlocking_destroy_function);*/ ... service apache2 start Starting web server: apache2DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=0 Segmentation fault Action 'start' failed. The Apache error log may have more information. failed! palik
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 11:23:08 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 914b
OK, so now if you 1/ put back all 3 lines: CRYPTO_set_dynlock_* 2/ comment out lines CRYPTO_set_locking_callback((void (*)(int,int,const char *,int))openssl_locking_function); CRYPTO_set_id_callback(openssl_threadid_func); CRYPTO_THREADID_set_callback(openssl_threadid_func); it probably will not segfault, right? As for mod_ssl do you have any idea whether it is loaded before mod_perl+net-ssleay or after? My theory is: - when net-ssleay is loaded (BOOT section executed) mod_ssl is not loaded yet - net-ssleay detects that openssl threading was not setup yet and will setup all necessary callbacks - later mod_ssl got loaded and forces re-setup of the openssl threading which probably causes inconsistency/crash If my guess is correct, I do not now what we can do on net-ssleay side (perhaps just document, that mod_ssl has to be loaded before mod_perl+net-ssleay). -- kmx
Download (untitled) / with headers
text/plain 1.7k
On Wed Mar 21 06:23:20 2012, kmx@volny.cz wrote: Show quoted text
> OK, so now if you > 1/ put back all 3 lines: CRYPTO_set_dynlock_* > 2/ comment out lines > CRYPTO_set_locking_callback((void (*)(int,int,const char > *,int))openssl_locking_function); > CRYPTO_set_id_callback(openssl_threadid_func); > CRYPTO_THREADID_set_callback(openssl_threadid_func); > it probably will not segfault, right?
Yes. # service apache2 start Starting web server: apache2 DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=0 [Tue Mar 20 01:08:18 2012] [notice] Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.0h mod_perl/2.0.5 Perl/v5.14.2 configured -- resuming normal operations Show quoted text
> As for mod_ssl do you have any idea whether it is loaded before > mod_perl+net-ssleay or after?
No idea, but I think apache load the modules in alphabetical order /etc/apache2/mods-enabled/perl.load /etc/apache2/mods-enabled/ssl.load I've tried to change the order and set it as follow: LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so Include mods-available/ssl.conf LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so in this case is the situation is same as in Show quoted text
> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
palik Show quoted text
> > My theory is: > - when net-ssleay is loaded (BOOT section executed) mod_ssl is not > loaded yet > - net-ssleay detects that openssl threading was not setup yet and will > setup all necessary callbacks > - later mod_ssl got loaded and forces re-setup of the openssl threading > which probably causes inconsistency/crash > If my guess is correct, I do not now what we can do on net-ssleay side > (perhaps just document, that mod_ssl has to be loaded before > mod_perl+net-ssleay). > > -- > kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 21 Mar 2012 12:45:28 +0100
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Show quoted text
> I've tried to change the order and set it as follow: > LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so > Include mods-available/ssl.conf > LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so > > in this case is the situation is same as in >
>> 1/ put back all 3 lines: CRYPTO_set_dynlock_* >>
It crahses, right? What I consider strange is that I do not see any "DEBUG CLONE" message in your output - it means that there is just one perl interpreter runnig (just perl's main tread tid=0); while at the same time there are probable couple of other Apache threads within the same process. In such a situation our simple implementation of openssl_threadid_func() obviously cannot not work correctly. We can: 1/ try to arrange things to make sure that mod_ssl initializes openssl threading before mod_perl+net-ssleay is loaded (which we should detect in openssl_threads_init) 2/ try put some heavier implementation of openssl_threadid_func() in net-ssleay To test idea 2/ could you please revert to rev321 + apply enclosed debug+pthreads_self_hack_r321.diff ? -- kmx

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 2.1k
first of all a new very interesting fact: on debian squeeze 6.0.4 apache2-mpm-prefork 2.2.16-6+squeeze6 r321+debug_messages_r321.diff work well # service apache2 restart Restarting web server: apache2 ... waiting [Wed Mar 21 13:23:05 2012] [notice] caught DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations I've expected segfault too. Are we sure segfault on wheezy is caused by net-ssleay? Show quoted text
>
> > I've tried to change the order and set it as follow: > > LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so > > Include mods-available/ssl.conf > > LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so > > > > in this case is the situation is same as in > >
> >> 1/ put back all 3 lines: CRYPTO_set_dynlock_* > >>
> > It crahses, right?
Yes Show quoted text
> > What I consider strange is that I do not see any "DEBUG CLONE" message > in your output - it means that there is just one perl interpreter runnig > (just perl's main tread tid=0); while at the same time there are > probable couple of other Apache threads within the same process. > > In such a situation our simple implementation of openssl_threadid_func() > obviously cannot not work correctly. > > We can: > 1/ try to arrange things to make sure that mod_ssl initializes openssl > threading before mod_perl+net-ssleay is loaded (which we should detect > in openssl_threads_init) > 2/ try put some heavier implementation of openssl_threadid_func() in > net-ssleay > > To test idea 2/ could you please revert to rev321 + apply enclosed > debug+pthreads_self_hack_r321.diff ?
probably you are expected any other result: # service apache2 restart Restarting web server: apache2DEBUG: BOOT start DEBUG: init - begin DEBUG: setting static locking DEBUG: setting dynamic locking DEBUG: init - end DEBUG: BOOT done: tid=0 my_perl=0 Segmentation fault Action 'start' failed. The Apache error log may have more information. failed! palik
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Tue, 27 Mar 2012 18:14:51 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 5.1k
Hi all, So I now have a Wheezy/Sid test environment. After following the instructions to reproduce, but using the latest net-ssleay from svn, there is still a crash, but it is not the same crash as was first reported (and which I believe was fixed) This crash has the trace: #0 0xb6671c70 in ?? () #1 0xb7054f59 in CRYPTO_THREADID_current () from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 #2 0xb70cf80c in ERR_remove_thread_state () from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 #3 0xb70cf8ab in ERR_remove_state () from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 #4 0xb67d4531 in ?? () from /usr/lib/apache2/modules/mod_ssl.so #5 0xb7f50b6e in apr_pool_clear () from /usr/lib/libapr-1.so.0 #6 0x80023445 in main () this is crashing inside openssl as called by mod_ssl. however the crash does not occur with just the apache mod_ssl or just the apache mod_perl enabled. ONly with them both enabled. Now, what appears to happen is that mod_perl loads, loading Net-SSLeay, which initialises openssl, and calls CRYPTO_THREADID_set_callback to set the callback to Net::SSLeays openssl_threadid_func OK so far. Then openssl functions are called, CRYPTO_THREADID_current calls openssl_threadid_func and openssl_threadid_func ruturns a sensible thread id. OK so far. Then sometime later during apache2 startup (after about 20 successful calls to openssl_threadid_func , the callback call by CRYPTO_THREADID_current crashes. At this stage the address where Net::SSLeays openssl_threadid_func _used_ to be is gone, and the memory cant be accessed. Looks like at this stage, Net::SSLeay has been _unloaded_ from the apache2 process, but openssl library has not, and openssl's callback to Net::SSLeays openssl_threadid_func crashes. So: I suppose we can ask 'why is Net::SSLeay (and maybe mod_perl) being unloaded?'. But the answer is prob irrelevant. Realistically I guess we need to find a way to get control when it _is_ unloaded and remove our thread callback function. I know this is what openssl_threads_cleanup used to do, but it was called at multiple times. How do we get control (once) at the right time? Cheers. On Wednesday, March 21, 2012 08:25:23 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > first of all a new very interesting fact: > on debian squeeze 6.0.4 > apache2-mpm-prefork 2.2.16-6+squeeze6 > r321+debug_messages_r321.diff work well > > # service apache2 restart > Restarting web server: apache2 ... waiting [Wed Mar 21 13:23:05 2012] > [notice] caught DEBUG: BOOT start > DEBUG: init - begin > DEBUG: setting static locking > DEBUG: setting dynamic locking > DEBUG: init - end > DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 > [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) mod_ssl/2.2.16 > OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal > operations > > I've expected segfault too. > Are we sure segfault on wheezy is caused by net-ssleay? >
> > > I've tried to change the order and set it as follow: > > > LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so > > > Include mods-available/ssl.conf > > > LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so > > > > > > in this case is the situation is same as in > > >
> > >> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
> > > > It crahses, right?
> > Yes >
> > What I consider strange is that I do not see any "DEBUG CLONE" message > > in your output - it means that there is just one perl interpreter runnig > > (just perl's main tread tid=0); while at the same time there are > > probable couple of other Apache threads within the same process. > > > > In such a situation our simple implementation of openssl_threadid_func() > > obviously cannot not work correctly. > > > > We can: > > 1/ try to arrange things to make sure that mod_ssl initializes openssl > > threading before mod_perl+net-ssleay is loaded (which we should detect > > in openssl_threads_init) > > 2/ try put some heavier implementation of openssl_threadid_func() in > > net-ssleay > > > > To test idea 2/ could you please revert to rev321 + apply enclosed > > debug+pthreads_self_hack_r321.diff ?
> > probably you are expected any other result: > # service apache2 restart > Restarting web server: apache2DEBUG: BOOT start > DEBUG: init - begin > DEBUG: setting static locking > DEBUG: setting dynamic locking > DEBUG: init - end > DEBUG: BOOT done: tid=0 my_perl=0 > Segmentation fault > Action 'start' failed. > The Apache error log may have more information. > failed! > > > palik
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Tue, 27 Mar 2012 20:55:01 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 5.9k
More on this below.... On Tuesday, March 27, 2012 04:14:54 AM mikem@open.com.au via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Hi all, > > So I now have a Wheezy/Sid test environment. > > After following the instructions to reproduce, but using the latest > net-ssleay from svn, there is still a crash, but it is not the same crash > as was first reported (and which I believe was fixed) > > This crash has the trace: > > #0 0xb6671c70 in ?? () > #1 0xb7054f59 in CRYPTO_THREADID_current () > from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 > #2 0xb70cf80c in ERR_remove_thread_state () > from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 > #3 0xb70cf8ab in ERR_remove_state () > from /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 > #4 0xb67d4531 in ?? () from /usr/lib/apache2/modules/mod_ssl.so > #5 0xb7f50b6e in apr_pool_clear () from /usr/lib/libapr-1.so.0 > #6 0x80023445 in main () > > > this is crashing inside openssl as called by mod_ssl. > > however the crash does not occur with just the apache mod_ssl or just the > apache mod_perl enabled. ONly with them both enabled. > > Now, what appears to happen is that mod_perl loads, loading Net-SSLeay, > which initialises openssl, and calls CRYPTO_THREADID_set_callback to set > the callback to Net::SSLeays openssl_threadid_func > OK so far. > > Then openssl functions are called, CRYPTO_THREADID_current calls > openssl_threadid_func and openssl_threadid_func ruturns a sensible thread > id. OK so far. > > Then sometime later during apache2 startup (after about 20 successful calls > to openssl_threadid_func , the callback call by CRYPTO_THREADID_current > crashes. At this stage the address where Net::SSLeays openssl_threadid_func > _used_ to be is gone, and the memory cant be accessed. > > Looks like at this stage, Net::SSLeay has been _unloaded_ from the apache2 > process, but openssl library has not, and openssl's callback to Net::SSLeays > openssl_threadid_func crashes. > > So: I suppose we can ask 'why is Net::SSLeay (and maybe mod_perl) being > unloaded?'. But the answer is prob irrelevant. > > Realistically I guess we need to find a way to get control when it _is_ > unloaded and remove our thread callback function. > > I know this is what openssl_threads_cleanup used to do, but it was called at > multiple times. How do we get control (once) at the right time?
Annoyingly, I observe different behaviours in md_perl??? with different versions of debian/apache/perl: eg if I add some code to print the thread id during BOOT, CLONE and END, during apache startup: Debian Squeeze 6.0.4: BOOT 0 CLONE 0 CLONE 0 CLONE 0 END 0 END 0 END 0 END 0 Debian Wheezy/Sid: BOOT 0 END 0 Sigh: how to make this work in both environments :-( Cheers. Show quoted text
> > > Cheers. > > On Wednesday, March 21, 2012 08:25:23 AM you wrote:
> > Queue: Net-SSLeay > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > first of all a new very interesting fact: > > on debian squeeze 6.0.4 > > apache2-mpm-prefork 2.2.16-6+squeeze6 > > r321+debug_messages_r321.diff work well > > > > # service apache2 restart > > Restarting web server: apache2 ... waiting [Wed Mar 21 13:23:05 2012] > > [notice] caught DEBUG: BOOT start > > DEBUG: init - begin > > DEBUG: setting static locking > > DEBUG: setting dynamic locking > > DEBUG: init - end > > DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 > > [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) > > mod_ssl/2.2.16 > > OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal > > operations > > > > I've expected segfault too. > > Are we sure segfault on wheezy is caused by net-ssleay? > >
> > > > I've tried to change the order and set it as follow: > > > > LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so > > > > Include mods-available/ssl.conf > > > > LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so > > > > > > > > in this case is the situation is same as in > > > >
> > > >> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
> > > > > > It crahses, right?
> > > > Yes > >
> > > What I consider strange is that I do not see any "DEBUG CLONE" > > > message > > > in your output - it means that there is just one perl interpreter > > > runnig (just perl's main tread tid=0); while at the same time there > > > are probable couple of other Apache threads within the same > > > process. > > > > > > In such a situation our simple implementation of > > > openssl_threadid_func() obviously cannot not work correctly. > > > > > > We can: > > > 1/ try to arrange things to make sure that mod_ssl initializes > > > openssl > > > threading before mod_perl+net-ssleay is loaded (which we should > > > detect > > > in openssl_threads_init) > > > 2/ try put some heavier implementation of openssl_threadid_func() in > > > net-ssleay > > > > > > To test idea 2/ could you please revert to rev321 + apply enclosed > > > debug+pthreads_self_hack_r321.diff ?
> > > > probably you are expected any other result: > > # service apache2 restart > > Restarting web server: apache2DEBUG: BOOT start > > DEBUG: init - begin > > DEBUG: setting static locking > > DEBUG: setting dynamic locking > > DEBUG: init - end > > DEBUG: BOOT done: tid=0 my_perl=0 > > Segmentation fault > > Action 'start' failed. > > The Apache error log may have more information. > > > > failed! > > > > palik
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Tue, 27 Mar 2012 15:28:57 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 2.5k
Show quoted text
>> Now, what appears to happen is that mod_perl loads, loading Net-SSLeay, >> which initialises openssl, and calls CRYPTO_THREADID_set_callback to set >> the callback to Net::SSLeays openssl_threadid_func >> OK so far. >> >> Then openssl functions are called, CRYPTO_THREADID_current calls >> openssl_threadid_func and openssl_threadid_func ruturns a sensible thread >> id. OK so far. >> >> Then sometime later during apache2 startup (after about 20 successful calls >> to openssl_threadid_func , the callback call by CRYPTO_THREADID_current >> crashes. At this stage the address where Net::SSLeays openssl_threadid_func >> _used_ to be is gone, and the memory cant be accessed. >> >> Looks like at this stage, Net::SSLeay has been _unloaded_ from the apache2 >> process, but openssl library has not, and openssl's callback to Net::SSLeays >> openssl_threadid_func crashes. >>
I have the same feeling, your analysis is IMHO correct (or very close to be correct) Show quoted text
>> So: I suppose we can ask 'why is Net::SSLeay (and maybe mod_perl) being >> unloaded?'. But the answer is prob irrelevant. >> >> Realistically I guess we need to find a way to get control when it _is_ >> unloaded and remove our thread callback function. >> >> I know this is what openssl_threads_cleanup used to do, but it was called at >> multiple times. How do we get control (once) at the right time? >>
It might be quite hard because as far as I have googled mod_perl does some dark magic with perl interprets - here is my understanding: - mod_perl has a pool of "parent" perl interprets (1 or more) started in separate threads - when a request comes the new cloned perl interpreter is derived from some of the parent interprets - the lifetime of perl interprets is fully driven by mod_perl (and they can probably be created/unloded/reloded/destroyed at any time) One thing we can do is to allow openssl_deinitialization only by perl interpret that has called openssl_initialization. However I am afraid that this will not solve our troubles completely. Consider this scenario of continuously loading/unloading perl interprets (again only my guess): - mod_perl loads 1st perl interpret - which calls_openssl_initi - mod_perl loads 2st perl interpret - no more init needed - mod_perl unloads 1st perl interpret - as it is "init-caller" it will call openssl deinitialization !!! - mod_perl loads 3st perl interpret - no more init needed, but it is likely to crash Is it somehow possible to detect that we are the only (=last) running perl interpret? Or maybe is it possible to detect that we are loaded by mod_perl ? (and skip openssl threading init) -- kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 08:43:23 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 5.6k
Yet more investigations: On Tuesday, March 27, 2012 08:55:01 PM you wrote: Show quoted text
> More on this below.... > > On Tuesday, March 27, 2012 04:14:54 AM mikem@open.com.au via RT wrote:
> > Queue: Net-SSLeay > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > Hi all, > > > > So I now have a Wheezy/Sid test environment.
.... Show quoted text
> > > > Realistically I guess we need to find a way to get control when it _is_ > > unloaded and remove our thread callback function. > > > > I know this is what openssl_threads_cleanup used to do, but it was > > called at multiple times. How do we get control (once) at the right > > time?
> Annoyingly, I observe different behaviours in md_perl??? with different > versions of debian/apache/perl: > > eg if I add some code to print the thread id during BOOT, CLONE and END, > during apache startup: > > Debian Squeeze 6.0.4: > BOOT 0 > CLONE 0 > CLONE 0 > CLONE 0 > END 0 > END 0 > END 0 > END 0 > > Debian Wheezy/Sid: > BOOT 0 > END 0 > > Sigh: how to make this work in both environments :-(
Apache2 in Squeeze and Wheezy appear to use mod_perl in quite different ways (at least with the default apache config) Squeeze has libapache2-mod-perl2 2.0.4-7 it does not use dlclose to close any shared libs during apache2 startup. The fixes we currently have in svn work fine with that. Wheezy/Sid has ibapache2-mod-perl2 2.0.5-5 it uses dlclose to unload Net-SSLeay during startup. Since no other module has that .so loaded, Debian unloads that .so from the apache address space. Subsequent operations by mod_ssl cause the access to the now unloaded net- ssleay addresses causing the crash. There is even worse news: Even if we could get control at the right time (and I think there _is_ in fact a chance of this), it is not possible to remove a callback set with openssl CRYPTO_THREADID_set_callback. The code is like this: int CRYPTO_THREADID_set_callback(void (*func)(CRYPTO_THREADID *)) { if (threadid_callback) return 0; threadid_callback = func; return 1; } so once threadid_callback is established you _cannot_ remove it. Perhaps that means we will have to fall back to CRYPTO_set_id_callback (if it is available: dependent on OPENSSL_NO_DEPRECATED) Or is there some way to prevent NetSSLeay.so being unloaded? Prob not. Or.....?????? Sigh. Show quoted text
> > > Cheers. >
> > Cheers. > > > > On Wednesday, March 21, 2012 08:25:23 AM you wrote:
> > > Queue: Net-SSLeay > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > > > first of all a new very interesting fact: > > > on debian squeeze 6.0.4 > > > apache2-mpm-prefork 2.2.16-6+squeeze6 > > > r321+debug_messages_r321.diff work well > > > > > > # service apache2 restart > > > Restarting web server: apache2 ... waiting [Wed Mar 21 13:23:05 > > > 2012] > > > [notice] caught DEBUG: BOOT start > > > DEBUG: init - begin > > > DEBUG: setting static locking > > > DEBUG: setting dynamic locking > > > DEBUG: init - end > > > DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 > > > [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) > > > mod_ssl/2.2.16 > > > OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming > > > normal operations > > > > > > I've expected segfault too. > > > Are we sure segfault on wheezy is caused by net-ssleay? > > >
> > > > > I've tried to change the order and set it as follow: > > > > > LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so > > > > > Include mods-available/ssl.conf > > > > > LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so > > > > > > > > > > in this case is the situation is same as in > > > > >
> > > > >> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
> > > > > > > > It crahses, right?
> > > > > > Yes > > >
> > > > What I consider strange is that I do not see any "DEBUG CLONE" > > > > message > > > > in your output - it means that there is just one perl > > > > interpreter > > > > runnig (just perl's main tread tid=0); while at the same time > > > > there > > > > are probable couple of other Apache threads within the same > > > > process. > > > > > > > > In such a situation our simple implementation of > > > > openssl_threadid_func() obviously cannot not work correctly. > > > > > > > > We can: > > > > 1/ try to arrange things to make sure that mod_ssl initializes > > > > openssl > > > > threading before mod_perl+net-ssleay is loaded (which we should > > > > detect > > > > in openssl_threads_init) > > > > 2/ try put some heavier implementation of > > > > openssl_threadid_func() in > > > > net-ssleay > > > > > > > > To test idea 2/ could you please revert to rev321 + apply > > > > enclosed > > > > debug+pthreads_self_hack_r321.diff ?
> > > > > > probably you are expected any other result: > > > # service apache2 restart > > > Restarting web server: apache2DEBUG: BOOT start > > > DEBUG: init - begin > > > DEBUG: setting static locking > > > DEBUG: setting dynamic locking > > > DEBUG: init - end > > > DEBUG: BOOT done: tid=0 my_perl=0 > > > Segmentation fault > > > Action 'start' failed. > > > The Apache error log may have more information. > > > > > > failed! > > > > > > palik
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 11:22:38 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
And more, after much looking inside mod_perl, mod_ssl, perl DynaLoader etc On Wednesday, March 28, 2012 08:43:23 AM Mike McCauley wrote: Show quoted text
> Yet more investigations: > > On Tuesday, March 27, 2012 08:55:01 PM you wrote:
> > More on this below.... > > > > On Tuesday, March 27, 2012 04:14:54 AM mikem@open.com.au via RT wrote:
> > > Queue: Net-SSLeay > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > > > Hi all, > > > > > > So I now have a Wheezy/Sid test environment.
> > .... >
> > > Realistically I guess we need to find a way to get control when it > > > _is_ > > > unloaded and remove our thread callback function. > > > > > > I know this is what openssl_threads_cleanup used to do, but it was > > > called at multiple times. How do we get control (once) at the right > > > time?
> > > > Annoyingly, I observe different behaviours in md_perl??? with different > > versions of debian/apache/perl: > > > > eg if I add some code to print the thread id during BOOT, CLONE and END, > > during apache startup: > > > > Debian Squeeze 6.0.4: > > BOOT 0 > > CLONE 0 > > CLONE 0 > > CLONE 0 > > END 0 > > END 0 > > END 0 > > END 0 > > > > Debian Wheezy/Sid: > > BOOT 0 > > END 0 > > > > Sigh: how to make this work in both environments :-(
> > Apache2 in Squeeze and Wheezy appear to use mod_perl in quite different ways > (at least with the default apache config) > > Squeeze has libapache2-mod-perl2 2.0.4-7 > it does not use dlclose to close any shared libs during apache2 startup. > The fixes we currently have in svn work fine with that. > > Wheezy/Sid has ibapache2-mod-perl2 2.0.5-5 > it uses dlclose to unload Net-SSLeay during startup. Since no other module > has that .so loaded, Debian unloads that .so from the apache address space. > Subsequent operations by mod_ssl cause the access to the now unloaded net- > ssleay addresses causing the crash. > > There is even worse news: > > Even if we could get control at the right time (and I think there _is_ in > fact a chance of this), it is not possible to remove a callback set with > openssl CRYPTO_THREADID_set_callback. The code is like this: > > int CRYPTO_THREADID_set_callback(void (*func)(CRYPTO_THREADID *)) > { > if (threadid_callback) > return 0; > threadid_callback = func; > return 1; > } > > so once threadid_callback is established you _cannot_ remove it. > > Perhaps that means we will have to fall back to CRYPTO_set_id_callback (if > it is available: dependent on OPENSSL_NO_DEPRECATED)
Hmmm, Apache 2.2 as used in Wheezy/Sid mod_ssl registers an id callback with the old CRYPTO_set_id_callback(ssl_util_thr_id); The thread id returned by ssl_util_thr_id is the apache thread, as returned by apr_os_thread_current(). Conclusion: apache+mod-ssl uses apache threads and thread IDs. Now if apache2 with mod_ssl loaded (a common case) loads mod_perl and Net::SSLeay and a perl app that wnats to use threading, perl will want to use its own threading model, which is utterly different to the threading in apache. So if Net::SSLeay changes or overrides the thread id callback that mod_ssl sets up. Is it not likely to break apache+mod_ssl threading? Perhaps there is a fundamental incompatibility between apache+mod-perl+perl+net-ssleay+threads and apache+mod-ssl Surely their different threading systems cannot co-exist within one process? Show quoted text
> > Or is there some way to prevent NetSSLeay.so being unloaded? Prob not. > > Or.....?????? > > Sigh. >
> > Cheers. > >
> > > Cheers. > > > > > > On Wednesday, March 21, 2012 08:25:23 AM you wrote:
> > > > Queue: Net-SSLeay > > > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841
> > > > >
> > > > > > > > first of all a new very interesting fact: > > > > on debian squeeze 6.0.4 > > > > apache2-mpm-prefork 2.2.16-6+squeeze6 > > > > r321+debug_messages_r321.diff work well > > > > > > > > # service apache2 restart > > > > Restarting web server: apache2 ... waiting [Wed Mar 21 13:23:05 > > > > 2012] > > > > [notice] caught DEBUG: BOOT start > > > > DEBUG: init - begin > > > > DEBUG: setting static locking > > > > DEBUG: setting dynamic locking > > > > DEBUG: init - end > > > > DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 > > > > [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) > > > > mod_ssl/2.2.16 > > > > OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- > > > > resuming > > > > normal operations > > > > > > > > I've expected segfault too. > > > > Are we sure segfault on wheezy is caused by net-ssleay? > > > >
> > > > > > I've tried to change the order and set it as follow: > > > > > > LoadModule ssl_module > > > > > > /usr/lib/apache2/modules/mod_ssl.so > > > > > > Include mods-available/ssl.conf > > > > > > LoadModule perl_module > > > > > > /usr/lib/apache2/modules/mod_perl.so > > > > > > > > > > > > in this case is the situation is same as in > > > > > >
> > > > > >> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
> > > > > > > > > > It crahses, right?
> > > > > > > > Yes > > > >
> > > > > What I consider strange is that I do not see any "DEBUG > > > > > CLONE" > > > > > message > > > > > in your output - it means that there is just one perl > > > > > interpreter > > > > > runnig (just perl's main tread tid=0); while at the same > > > > > time > > > > > there > > > > > are probable couple of other Apache threads within the same > > > > > process. > > > > > > > > > > In such a situation our simple implementation of > > > > > openssl_threadid_func() obviously cannot not work correctly. > > > > > > > > > > We can: > > > > > 1/ try to arrange things to make sure that mod_ssl > > > > > initializes > > > > > openssl > > > > > threading before mod_perl+net-ssleay is loaded (which we > > > > > should > > > > > detect > > > > > in openssl_threads_init) > > > > > 2/ try put some heavier implementation of > > > > > openssl_threadid_func() in > > > > > net-ssleay > > > > > > > > > > To test idea 2/ could you please revert to rev321 + apply > > > > > enclosed > > > > > debug+pthreads_self_hack_r321.diff ?
> > > > > > > > probably you are expected any other result: > > > > # service apache2 restart > > > > Restarting web server: apache2DEBUG: BOOT start > > > > DEBUG: init - begin > > > > DEBUG: setting static locking > > > > DEBUG: setting dynamic locking > > > > DEBUG: init - end > > > > DEBUG: BOOT done: tid=0 my_perl=0 > > > > Segmentation fault > > > > Action 'start' failed. > > > > The Apache error log may have more information. > > > > > > > > failed! > > > > > > > > palik
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 17:59:19 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 8.7k
On Tuesday, March 27, 2012 09:22:40 PM mikem@open.com.au via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > And more, after much looking inside mod_perl, mod_ssl, perl DynaLoader etc > > On Wednesday, March 28, 2012 08:43:23 AM Mike McCauley wrote:
> > Yet more investigations: > > > > On Tuesday, March 27, 2012 08:55:01 PM you wrote:
> > > More on this below.... > > > > > > On Tuesday, March 27, 2012 04:14:54 AM mikem@open.com.au via RT wrote:
> > > > Queue: Net-SSLeay > > > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841
> > > > >
> > > > > > > > Hi all, > > > > > > > > So I now have a Wheezy/Sid test environment.
> > > > .... > >
> > > > Realistically I guess we need to find a way to get control when > > > > it > > > > _is_ > > > > unloaded and remove our thread callback function. > > > > > > > > I know this is what openssl_threads_cleanup used to do, but it > > > > was > > > > called at multiple times. How do we get control (once) at the > > > > right > > > > time?
> > > > > > Annoyingly, I observe different behaviours in md_perl??? with > > > different > > > versions of debian/apache/perl: > > > > > > eg if I add some code to print the thread id during BOOT, CLONE and > > > END, during apache startup: > > > > > > Debian Squeeze 6.0.4: > > > BOOT 0 > > > CLONE 0 > > > CLONE 0 > > > CLONE 0 > > > END 0 > > > END 0 > > > END 0 > > > END 0 > > > > > > Debian Wheezy/Sid: > > > BOOT 0 > > > END 0
Those thread ids are all 0 because threads is not loaded at this time (even though there appear to be multiple perl interpreters in the same process! More info: Squeeze has apache built with MPM worker, but Wheezy/Sid is MPM prefork. I must say I still dont really understand what happens in mod_perl during apache startup However, tests have shown on Debian squeeze that any attempt to create a perl thread in a mod-perl+ModPerl::PerlRun script will cause a nasty apache crash, even if Net::SSLeay or mod-ssl is not loaded or used. Ive not seen any discussion of using perl threads in a mod-perl script, so perhaps its not supported? And if one is using apache MPM, its not even necessary? So, maybe given that this does not work: apache2+mod-ssl+mod-perl+perlthreads nor this: apache2+mod-perl+perlthreads then we should not be trying to make it work with apache2+mod-ssl+mod-perl+NetSSLeay+perlthreads and only try to make it work under apache2+mod-ssl+mod-perl+NetSSLeay and perl+NetSSLeay+perlthreads (there may be some hope of that :-)) Ive had enough for one day...... Cheers. Show quoted text
> > > > > > Sigh: how to make this work in both environments :-(
> > > > Apache2 in Squeeze and Wheezy appear to use mod_perl in quite different > > ways (at least with the default apache config) > > > > Squeeze has libapache2-mod-perl2 2.0.4-7 > > it does not use dlclose to close any shared libs during apache2 startup. > > The fixes we currently have in svn work fine with that. > > > > Wheezy/Sid has ibapache2-mod-perl2 2.0.5-5 > > it uses dlclose to unload Net-SSLeay during startup. Since no other > > module has that .so loaded, Debian unloads that .so from the apache > > address space. Subsequent operations by mod_ssl cause the access to the > > now unloaded net- ssleay addresses causing the crash. > > > > There is even worse news: > > > > Even if we could get control at the right time (and I think there _is_ > > in > > fact a chance of this), it is not possible to remove a callback set with > > openssl CRYPTO_THREADID_set_callback. The code is like this: > > > > int CRYPTO_THREADID_set_callback(void (*func)(CRYPTO_THREADID *)) > > > > { > > if (threadid_callback) > > > > return 0; > > > > threadid_callback = func; > > return 1; > > } > > > > so once threadid_callback is established you _cannot_ remove it. > > > > Perhaps that means we will have to fall back to CRYPTO_set_id_callback > > (if it is available: dependent on OPENSSL_NO_DEPRECATED)
> > Hmmm, Apache 2.2 as used in Wheezy/Sid mod_ssl registers an id callback with > the old CRYPTO_set_id_callback(ssl_util_thr_id); > > The thread id returned by ssl_util_thr_id is the apache thread, as returned > by apr_os_thread_current(). Conclusion: apache+mod-ssl uses apache threads > and thread IDs. > > Now if apache2 with mod_ssl loaded (a common case) loads mod_perl and > Net::SSLeay and a perl app that wnats to use threading, perl will want to > use its own threading model, which is utterly different to the threading in > apache. > > So if Net::SSLeay changes or overrides the thread id callback that mod_ssl > sets up. Is it not likely to break apache+mod_ssl threading? > > Perhaps there is a fundamental incompatibility between > apache+mod-perl+perl+net-ssleay+threads > and > apache+mod-ssl > > Surely their different threading systems cannot co-exist within one process?
> > Or is there some way to prevent NetSSLeay.so being unloaded? Prob not. > > > > Or.....?????? > > > > Sigh. > >
> > > Cheers. > > >
> > > > Cheers. > > > > > > > > On Wednesday, March 21, 2012 08:25:23 AM you wrote:
> > > > > Queue: Net-SSLeay > > > > > > > > > > Ticket <URL: > > > > > https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > > > > > > first of all a new very interesting fact: > > > > > on debian squeeze 6.0.4 > > > > > apache2-mpm-prefork 2.2.16-6+squeeze6 > > > > > r321+debug_messages_r321.diff work well > > > > > > > > > > # service apache2 restart > > > > > Restarting web server: apache2 ... waiting [Wed Mar 21 > > > > > 13:23:05 > > > > > 2012] > > > > > [notice] caught DEBUG: BOOT start > > > > > DEBUG: init - begin > > > > > DEBUG: setting static locking > > > > > DEBUG: setting dynamic locking > > > > > DEBUG: init - end > > > > > DEBUG: BOOT done: tid=0 my_perl=7fbe6e600b30 > > > > > [Wed Mar 21 13:23:06 2012] [notice] Apache/2.2.16 (Debian) > > > > > mod_ssl/2.2.16 > > > > > OpenSSL/0.9.8o mod_perl/2.0.4 Perl/v5.10.1 configured -- > > > > > resuming > > > > > normal operations > > > > > > > > > > I've expected segfault too. > > > > > Are we sure segfault on wheezy is caused by net-ssleay? > > > > >
> > > > > > > I've tried to change the order and set it as follow: > > > > > > > LoadModule ssl_module > > > > > > > /usr/lib/apache2/modules/mod_ssl.so > > > > > > > Include mods-available/ssl.conf > > > > > > > LoadModule perl_module > > > > > > > /usr/lib/apache2/modules/mod_perl.so > > > > > > > > > > > > > > in this case is the situation is same as in > > > > > > >
> > > > > > >> 1/ put back all 3 lines: CRYPTO_set_dynlock_*
> > > > > > > > > > > > It crahses, right?
> > > > > > > > > > Yes > > > > >
> > > > > > What I consider strange is that I do not see any "DEBUG > > > > > > CLONE" > > > > > > message > > > > > > in your output - it means that there is just one perl > > > > > > interpreter > > > > > > runnig (just perl's main tread tid=0); while at the same > > > > > > time > > > > > > there > > > > > > are probable couple of other Apache threads within the > > > > > > same > > > > > > process. > > > > > > > > > > > > In such a situation our simple implementation of > > > > > > openssl_threadid_func() obviously cannot not work > > > > > > correctly. > > > > > > > > > > > > We can: > > > > > > 1/ try to arrange things to make sure that mod_ssl > > > > > > initializes > > > > > > openssl > > > > > > threading before mod_perl+net-ssleay is loaded (which we > > > > > > should > > > > > > detect > > > > > > in openssl_threads_init) > > > > > > 2/ try put some heavier implementation of > > > > > > openssl_threadid_func() in > > > > > > net-ssleay > > > > > > > > > > > > To test idea 2/ could you please revert to rev321 + > > > > > > apply > > > > > > enclosed > > > > > > debug+pthreads_self_hack_r321.diff ?
> > > > > > > > > > probably you are expected any other result: > > > > > # service apache2 restart > > > > > Restarting web server: apache2DEBUG: BOOT start > > > > > DEBUG: init - begin > > > > > DEBUG: setting static locking > > > > > DEBUG: setting dynamic locking > > > > > DEBUG: init - end > > > > > DEBUG: BOOT done: tid=0 my_perl=0 > > > > > Segmentation fault > > > > > Action 'start' failed. > > > > > The Apache error log may have more information. > > > > > > > > > > failed! > > > > > > > > > > palik
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 10:54:29 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.1k
With more info about this issue I thing that the only way to make it work is to simply somehow skip openssl thread locking initialization in Net::SSleay when running under Apache+mod_perl+mod_ssl 1/ If we can assure that mod_ssl loads + initializes thread locking "reliably-before" Net::SSley is loaded then I hope our openssl_threads_init() will detect such a situation and will not initialize openssl thread locking again 2/ If we can detect (inside SSLeay.xs's BOOT: section) that we are running under mod_perl then we can completely skip the call to openssl_threads_init() Anyway: - Net::SSLeay is able to work 100% correctly with openssl thread locking setup by mod_ssl - mod_ssl is IMHO sooner or later gonna crash with openssl thread locking setup by Net::SSLeay (as Net::SSLeay is not aware of other threads than perl-ithreads) Ad mod_perl detection I have found: http://stackoverflow.com/questions/9668392/how-can-my-perl-program-tell-if-is-running-under-mod-perl So what about a simple patch in BOOT section like: - openssl_threads_init(); + if (!PerlEnv_getenv("MOD_PERL")) openssl_threads_init(); can anyone test this? -- kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 21:28:17 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 2.3k
Hi, On Wednesday, March 28, 2012 04:54:41 AM kmx via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > With more info about this issue I thing that the only way to make it > work is to simply somehow skip openssl thread locking initialization in > Net::SSleay when running under Apache+mod_perl+mod_ssl > > 1/ If we can assure that mod_ssl loads + initializes thread locking > "reliably-before" Net::SSley is loaded then I hope our > openssl_threads_init() will detect such a situation and will not > initialize openssl thread locking again > > 2/ If we can detect (inside SSLeay.xs's BOOT: section) that we are > running under mod_perl then we can completely skip the call to > openssl_threads_init() > > Anyway: > - Net::SSLeay is able to work 100% correctly with openssl thread locking > setup by mod_ssl > - mod_ssl is IMHO sooner or later gonna crash with openssl thread > locking setup by Net::SSLeay (as Net::SSLeay is not aware of other > threads than perl-ithreads) > > Ad mod_perl detection I have found: > http://stackoverflow.com/questions/9668392/how-can-my-perl-program-tell-if-i > s-running-under-mod-perl > > So what about a simple patch in BOOT section like: > - openssl_threads_init(); > + if (!PerlEnv_getenv("MOD_PERL")) openssl_threads_init(); > > can anyone test this?
Yes, it works fine in almost every case Fine on linux and windows (not under apache) On Wheezy/Sid apache PerlEnv_getenv("MOD_PERL") does not detect that we are running under mod-perl, therfore openssl_threads_init() stil runs therefore crash. Strangely, on Squeeze apache, it works fine and openssl_threads_init() does not run. Who sets the env var MOD_PERL? When? Nearly There!!!!! Cheers. Show quoted text
> > -- > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 13:37:10 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 554b
Show quoted text
> On Wheezy/Sid apache > PerlEnv_getenv("MOD_PERL") > does not detect that we are running under mod-perl, therfore > openssl_threads_init() stil runs therefore crash. > > Strangely, on Squeeze apache, it works fine and openssl_threads_init() does > not run. > > Who sets the env var MOD_PERL? When? >
More info here: http://perl.apache.org/docs/2.0/user/coding/coding.html#Environment_Variables Quote: "If $ENV{MOD_PERL} doesn't exist, most likely you are not running under mod_perl." Maybe try MOD_PERL_API_VERSION instead of MOD_PERL -- kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 22:02:14 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 1.7k
Hi, On Wednesday, March 28, 2012 07:37:25 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > >
> > On Wheezy/Sid apache > > PerlEnv_getenv("MOD_PERL") > > does not detect that we are running under mod-perl, therfore > > openssl_threads_init() stil runs therefore crash. > > > > Strangely, on Squeeze apache, it works fine and openssl_threads_init() > > does not run. > > > > Who sets the env var MOD_PERL? When?
> > More info here: > http://perl.apache.org/docs/2.0/user/coding/coding.html#Environment_Variable > s > > Quote: "If $ENV{MOD_PERL} doesn't exist, most likely you are not running > under mod_perl."
Yes, I read that, but both PerlEnv_getenv("MOD_PERL") and PerlEnv_getenv("MOD_PERL_API_VERSION") both return NULL inside BOOT on both Wheezy and Squeeze. I incorrectly stated it was OK on Squeeze before. My mistake. Forgot I had disabled Net::SSLeay in mod_perl. I dont know why the env vars are not detected. Perhaps they are set after the PerlModule modules are loaded? Are you sure PerlEnv_getenv("MOD_PERL") will get them it? Cheers. Show quoted text
> > Maybe try MOD_PERL_API_VERSION instead of MOD_PERL > > -- > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 14:02:12 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 247b
Mike, maybe slightly OT - I propose adding (permanently) more diagnostics into SSLeay.xs - see a simple patch more_xs_debug_diagnostics_r331.diff it is normally turned off, it can be enabled by: perl Makefile.PL DEFINE=-DSHOW_XS_DEBUG -- kmx

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 22:08:08 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 2.2k
Hi again, more on this: On Wednesday, March 28, 2012 10:02:14 PM Mike McCauley wrote: Show quoted text
> Hi, > > On Wednesday, March 28, 2012 07:37:25 AM you wrote:
> > Queue: Net-SSLeay > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > >
> > > On Wheezy/Sid apache > > > PerlEnv_getenv("MOD_PERL") > > > does not detect that we are running under mod-perl, therfore > > > openssl_threads_init() stil runs therefore crash. > > > > > > Strangely, on Squeeze apache, it works fine and > > > openssl_threads_init() > > > does not run. > > > > > > Who sets the env var MOD_PERL? When?
> > > > More info here: > > http://perl.apache.org/docs/2.0/user/coding/coding.html#Environment_Vari > > able s > > > > Quote: "If $ENV{MOD_PERL} doesn't exist, most likely you are not running > > under mod_perl."
> > Yes, I read that, but both > > PerlEnv_getenv("MOD_PERL") > and > PerlEnv_getenv("MOD_PERL_API_VERSION") > > both return NULL inside BOOT on both Wheezy and Squeeze. > > I incorrectly stated it was OK on Squeeze before. My mistake. Forgot I had > disabled Net::SSLeay in mod_perl. > > I dont know why the env vars are not detected. Perhaps they are set after > the PerlModule modules are loaded? > > Are you sure PerlEnv_getenv("MOD_PERL") will get them it?
Hmm perl code print "HERE $ENV{MOD_PERL}\n"; at the top of Net::SSLeay.pm sees MOD_PERL set, but printf("HERE %s\n", PerlEnv_getenv("MOD_PERL")); in BOOT does not, even though it runs AFTER the perl code. I note that mod_perl adds MOD_PERL direct to the ENV hash, and not to the actual process environment. Is that relevant? Where does PerlEnv_getenv get it from? Show quoted text
> > Cheers. >
> > Maybe try MOD_PERL_API_VERSION instead of MOD_PERL > > > > -- > > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 22:11:02 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 1.1k
Hi, yes, that looks fine. Ill apply it tomorrow... I think we are very close on the apache segfault thing, so lets sort that first. Cheers. On Wednesday, March 28, 2012 08:02:23 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Mike, > > maybe slightly OT - I propose adding (permanently) more diagnostics into > SSLeay.xs - see a simple patch more_xs_debug_diagnostics_r331.diff > > it is normally turned off, it can be enabled by: perl Makefile.PL > DEFINE=-DSHOW_XS_DEBUG > > -- > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 15:00:21 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 274b
Show quoted text
> I note that mod_perl adds MOD_PERL direct to the ENV hash, and not to the > actual process environment. Is that relevant? Where does PerlEnv_getenv get it > from? >
In that case try: if (hv_fetch(get_hv("ENV", 1), "MOD_PERL", 8, 0)) openssl_threads_init(); -- kmx
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Wed, 28 Mar 2012 15:01:55 +0200
To: bug-Net-SSLeay [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Sorry I meant: if (!hv_fetch(get_hv("ENV", 1), "MOD_PERL", 8, 0)) openssl_threads_init();
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Thu, 29 Mar 2012 06:56:22 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 903b
Hi, Yes that works fine everywhere. Great Work! Cheers. On Wednesday, March 28, 2012 09:02:06 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Sorry I meant: > > if (!hv_fetch(get_hv("ENV", 1), "MOD_PERL", 8, 0)) openssl_threads_init();
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Thu, 29 Mar 2012 07:02:44 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
HI, Thanks. Most of this is now in commit 332, along with the Debian segfault fix. On Wednesday, March 28, 2012 08:02:23 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Mike, > > maybe slightly OT - I propose adding (permanently) more diagnostics into > SSLeay.xs - see a simple patch more_xs_debug_diagnostics_r331.diff > > it is normally turned off, it can be enabled by: perl Makefile.PL > DEFINE=-DSHOW_XS_DEBUG > > -- > kmx
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
CC: info [...] maximka.de, kmx [...] cpan.org, 661566-submitter [...] bugs.debian.org, 661566 [...] bugs.debian.org
Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Sat, 31 Mar 2012 09:18:50 +0200
To: "mikem [...] open.com.au via RT" <bug-Net-SSLeay [...] rt.cpan.org>
From: Salvatore Bonaccorso <carnil [...] debian.org>
Download (untitled) / with headers
text/plain 571b
Hi all On Wed, Mar 28, 2012 at 04:56:20PM -0400, mikem@open.com.au via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Hi, > > Yes that works fine everywhere. > Great Work!
Sorry for the late answer, I was quite busy. I tried the patch from [1] applied to the Debian package. [1] http://anonscm.debian.org/viewvc/net-ssleay/trunk/SSLeay.xs?r1=331&r2=332 Apache2 at least does not segfault now anymore. I applied the patch to our git repository, but haven't uploaded yet. Many thanks for your work on this issue! Best regards, Salvatore
Download signature.asc
application/pgp-signature 836b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #75841] libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process
Date: Mon, 02 Apr 2012 18:40:35 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 1.4k
Hi, Thanks for testing. We expect to make a new full release very soon. Cheers. On Saturday, March 31, 2012 03:19:04 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > Hi all > > On Wed, Mar 28, 2012 at 04:56:20PM -0400, mikem@open.com.au via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=75841 > > > > > Hi, > > > > Yes that works fine everywhere. > > Great Work!
> > Sorry for the late answer, I was quite busy. > > I tried the patch from [1] applied to the Debian package. > > [1] > http://anonscm.debian.org/viewvc/net-ssleay/trunk/SSLeay.xs?r1=331&r2=332 > > Apache2 at least does not segfault now anymore. I applied the patch to > our git repository, but haven't uploaded yet. > > Many thanks for your work on this issue! > > Best regards, > Salvatore
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
New release 1.46 today will include this fix


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.