Bug 68703 – gcj's java.net.ServerSocket.close() fails to cause threads blocked in ServerSocket.accept() to throw a SocketException immediately as per specifications

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Byron Shelden 2004-10-24 07:41:13 UTC]

This is probably going upstream.
ServerSocket.accept() does in fact throw a SocketException when another thread calls ServerSocket.close(), but it only seems to do so either when I trap a second signal (my application uses the CNI and a C++ module to do signal trapping) or immediately when accept() has been called after already closing the ServerSocket. (the server thread runs in a loop until accept() throws an exception)

Reproducible: Always
Steps to Reproduce:
1. Have one thread block on SocketServer.accept()
2. Have another thread calls SocketServer.close()
3. Note the accept() thread does not throw an Exception.  In fact, it still accepts a connection!

Actual Results:  
The accept() thread accepted one last connection, but when the loop repeated,
the accept() call threw a SocketException as expected.

Expected Results:  
The accept() thread should have immediately thrown a SocketException and any
further attempt to connect to the port should have failed.

I am running gcc with these use flags
sys-devel/gcc-3.3.4-r1  +X -bootstrap -build -debug -debug +f77 +gcj -hardened
-multilib +nls -objc -pic -static -(uclibc)

gcj -v reports this:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libgcj.spec
rename spec lib to liborig
Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++,java --enable-threads=posix --enable-long-long
--disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3
--with-local-prefix=/usr/local --enable-shared --enable-nls
--without-included-gettext --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib
--with-x --disable-multilib --enable-__cxa_atexit --enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)

[Comment 1 Byron Shelden 2004-11-26 22:12:09 UTC]

Just a friendly poke a month later.  Anybody working on this?

[Comment 2 SpanKY 2004-12-06 19:45:08 UTC]

probably not

[Comment 3 Karl Trygve Kalleberg (RETIRED) 2004-12-18 16:20:16 UTC]

Nothing we can do about this I'm afraid. I know they're working heavily on 
gcj upstream, so you'll just have to wait 'till it slides into our tree.

If you can find a patch, perhaps you can persuade [e-mail]
to apply it?