From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
Gecko/20021120 Netscape/7.01

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



Hello

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.


 Best Regards-
 Tim Bell    tim.bell         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):


How reproducible:
Always

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

Additional info:

original debugging information sent to sun is available upon request.

I could not post hit here - do to length