From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
Description of problem:
During testing of a homegrown VNC ssl enabled proxy - we determined that a java
application handling ssl network communication would die when portscanned.
We submitted our bug-reports against 1.4.x to Sun for analysis.
Included below is their analysis of the problem, which points to a problem in
nss_ldap (in source versions < 200) with how it handles the SIGPIPE handler.
------------from sun below--------------
Subject: Re: (Review ID: 179108) JVM crashes
(JVM_handle_linux_signal+0x93) ) OutputStream
Thank you for reporting this issue.
This bug is being tracked under the following Bug-ID: 4630104
Synopsis: REGRESSION: JVM crash on unexpected EOF/SIGPIPE
The problem is in libnss_ldap.so.
_nss_ldap_enter tries to block SIGPIPE by changing the SIGPIPE handler to
SIG_IGN, and in _nss_ldap_leave, the original signal handler (in this case,
the JVM signalHandler) is restored by using sigset() or signal().
We set up our SIGPIPE handler first by sigaction() and with the SA_SIGINFO
flag set, so we get both siginfo and ucontext in the signal handler; but
sigset() and/or signal() used by nss_ldap can only restore signal
handlers without siginfo/ucontext.
As the result, when a SIGPIPE is delivered after nss_ldap has changed and
"restored" the SIGPIPE handler, our signal handler is invoked with only
one argument (i.e. signal number), but we expect three arguments (signal
number, siginfo and ucontext). We will crash when we try to figure out
the PC from ucontext (JVM_handle_linux_signal+0x93 is
"pc = (address) uc->uc_mcontext.gregs[REG_EIP];"). nss_ldap should use
sigaction() to change and restore signal handlers.
libjsig.so is designed to work around this type of problems. libjsig.so
works by interposing signal(), sigset() and sigaction() functions to
make sure JVM can still function correctly when any of the functions
is used to change a signal that is also being used by JVM.
Note from the ChangeLog, nss_ldap from version 200 started to use
sigprocmask() to block SIGPIPE. This should fix the problem.
If you don't have the latest nss_ldap (Redhat 8.1 beta has nss_ldap-202,
therefore does not have this problem), you can preload libjsig.so to work
around the problem.
Tim Bell firstname.lastname@example.org Core Java Engineering
Sun Microsystems Java Software
"JavaSoft(TM), Java(TM), and Java(TM) Development Kit
are all trademarks of Sun Microsystems, Inc."
"JavaSoft(TM), Java(TM), et Java(TM) Development Kit
sont des marques d?pos?es ou enregistr?es de Sun
Microsystems, Inc. aux Etats-Unis et dans d'autres pays."
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run a java program accepting SSL connections w/ 1.4.x on RH 7.3
2. Use nmap/tool of choice to portscan the listening port
3. Watch the program die immediate death
Actual Results: Process dies
Expected Results: No effect
original debugging information sent to sun is available upon request.
I could not post hit here - do to length
Upon a second search of existing bugs, bug 14656 might be caused by a bug
similar to this.
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.
If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.
Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
Closing as CANTFIX.