[Bug libgcj/15430] New: Cannot interrupt blocking I/O calls with close()

[Bug libgcj/15430] New: Cannot interrupt blocking I/O calls with close()

[mckinlay at redhat dot com]

When close() is called on a Socket or ServerSocket, it should cause a
SocketException to be thrown on any thread which is blocked on I/O operations on
that socket.

In libgcj, no exception is thrown, and the I/O thread remains blocked even
though the socket has been closed.

The attached test case demonstrates the problem for accept() and read(). The
problem most likely occurs for other calls such as write() and connect() as
well. This test case should be extended to cover these other calls, and added to
mauve.

-- 
           Summary: Cannot interrupt blocking I/O calls with close()
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mckinlay at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-05-14 01:26 -------
Created an attachment (id=6278)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6278&action=view)
Test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-14 01:29 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-05-14 01:29:28
               date|                            |
            Version|unknown                     |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-14 06:59 -------
FAIL: wrong exception: java.io.IOException: Bad file descriptor
FAIL: read() did not interrupt on close().
FAIL: read() did not interrupt on close().
FAIL: accept() did not interrupt on close().

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2004-05-14 01:29:28         |2004-08-14 06:59:01
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[konqueror at gmx dot de]

------- Additional Comments From konqueror at gmx dot de  2005-01-15 22:30 -------
I'm working on it 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |konqueror at gmx dot de
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[guilhem at kaffe dot org]

------- Comment #11 from guilhem at kaffe dot org  2005-11-25 19:10 -------
I feel a potential race condition in this patch. What happens in that case ?

thread 2:
  => PlainSocketImpl.accept
  => enters _Jv_select

thread 1:
  => shutdown socket
  => close socket
thread 3:
  => create another socket which occurs to have the same fd.
thread 2:
  => select wakes up
  => we call accept with the old fd

thread 1:
  => set native_fd to -1

I expect this scheme may be a flaw and it is not forbidden by the current code.
A simple fix would be to add a synchronization lock before accepting the
connection.

Wrong ?


-- 

guilhem at kaffe dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guilhem at kaffe dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[daney at gcc dot gnu dot org]

------- Comment #10 from daney at gcc dot gnu dot org  2005-11-15 19:16 -------
Fixed by committed patch.


-- 

daney at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[daney at gcc dot gnu dot org]

------- Comment #9 from daney at gcc dot gnu dot org  2005-11-15 19:11 -------
Subject: Bug 15430

Author: daney
Date: Tue Nov 15 19:11:53 2005
New Revision: 107036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107036
Log:
        PR libgcj/15430
        * gnu/java/net/natPlainSocketImplPosix.cc (throw_on_sock_closed): New
        function.
        (accept): Call it.
        (close): Call shutdown before closing.
        (read()): Call read_helper with proper parameters.
        (read(buffer, int, int)): Likewise.
        (read_helper):  Pass pointer to the PlainSocketImpl, remove native_fd
        and timeout parameters.  Make prototype to match. Use 
        pointer to PlainSocketImpl to access members. Call throw_on_sock_closed
        in two places.

Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/gnu/java/net/natPlainSocketImplPosix.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[daney at gcc dot gnu dot org]

------- Comment #8 from daney at gcc dot gnu dot org  2005-11-10 00:34 -------
New patch at:

http://gcc.gnu.org/ml/java-patches/2005-q4/msg00179.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[daney at gcc dot gnu dot org]

------- Comment #7 from daney at gcc dot gnu dot org  2005-11-09 19:24 -------
Here is the first version of my patch:

http://gcc.gnu.org/ml/java-patches/2005-q4/msg00176.html


-- 

daney at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[aph at gcc dot gnu dot org]

------- Comment #6 from aph at gcc dot gnu dot org  2005-11-09 18:22 -------
Two things:

Does this work for fds that aren't associated with sockets?

It doesn't quite avoid the need for locking, since we still need to make sure
that we only close an fd once.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430

[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()

[daney at gcc dot gnu dot org]

------- Comment #5 from daney at gcc dot gnu dot org  2005-11-09 17:46 -------
Created an attachment (id=10189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10189&action=view)
Program that demonstrates how shutdown can solve the problem.

Compile socktest.c thusly:

gcc -g -o soctest soctest.c -lpthread

Then run it and from a different window telnet localhost 4455

Do not type anything in the telnet window.

When the socket is shutdown the read returns with a value of zero.

I guess we should shutdown as well as close in the socket code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430