You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Paulex Yang (JIRA)" <ji...@apache.org> on 2006/05/19 07:13:29 UTC

[jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
------------------------------------------------------------------------------------

         Key: HARMONY-479
         URL: http://issues.apache.org/jira/browse/HARMONY-479
     Project: Harmony
        Type: Bug

  Components: Classlib  
    Reporter: Paulex Yang


If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.

    public void close() throws IOException {
            synchronized (channel) {
                synchronized (this) {
                    if (channel.isOpen() && fd.descriptor >= 0) {
                        channel.close();
                    }
                    fd.descriptor = -1;
                }
            }
    }

This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.


public class FileInputStreamTest {
    public static void main(String[] args) throws Exception{
        FileInputStream is = null;
        try{
            is = new FileInputStream(new File("nonexist"));
        }catch(Exception e){
            System.gc();
            e.printStackTrace();
        }
    }
}




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by George Harley <ge...@googlemail.com>.
Gregory Shimansky wrote:
> Hello Paulex
>
> I have a question about this problem. Do you know how exception in 
> finalizer
> method affects the finalizer thread that it becomes suspended? I thought
> that when calling finalize method the code should catch all exceptions
> thrown by it and ignore them. AFAIK that's how finalizers are 
> implemented in
> DRLVM. It specification it is written that
>
> "If an uncaught exception is thrown by the finalize method, the 
> exception is
> ignored and finalization of that object terminates."

Hi Gregory,

I'll let Paulex speak for himself but just thought I'd mention that the 
NPE does not occur when the test case in the JIRA is run against a RI. I 
appreciate what you are saying about finalizers but IMHO it is also good 
to bring our behaviour (even in an "edge case" like this) into line with 
the RI.


Best regards,
George

>
>
> 2006/5/19, Paulex Yang (JIRA) <ji...@apache.org>:
>>
>> java.io.FileInputStream and FileOutputStream might cause Finalizer 
>> thread
>> suspending
>>
>> ------------------------------------------------------------------------------------ 
>>
>>
>>          Key: HARMONY-479
>>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>>      Project: Harmony
>>         Type: Bug
>>
>>   Components: Classlib
>>     Reporter: Paulex Yang
>>
>>
>> If one FileInputStream instance is not constructed properly, say, the
>> given file doesn't exist, the constructor will throw exception but the
>> FileInputStream instance is still necessary to be garbage collected, 
>> and the
>> spec of FileInputStream's finalize() method requires that close() 
>> must be
>> invoked, but the current implementation of FileInputStream.close()(as
>> below) will causes NullPointerException in Finalizer thread because 
>> channel
>> field has not been initialized yet.
>>
>>     public void close() throws IOException {
>>             synchronized (channel) {
>>                 synchronized (this) {
>>                     if (channel.isOpen() && fd.descriptor >= 0) {
>>                         channel.close();
>>                     }
>>                     fd.descriptor = -1;
>>                 }
>>             }
>>     }
>>
>> This issue applies to FileOutputStream, too. Test case below can 
>> reproduce
>> this issue only in debugger, because it is not easy to get the handle of
>> Finalizer thread. Debugging the test case to the statement following the
>> System.gc(), the debugger will show that the Finalizer thread is 
>> suspended
>> due to NullPointerException.
>>
>>
>> public class FileInputStreamTest {
>>     public static void main(String[] args) throws Exception{
>>         FileInputStream is = null;
>>         try{
>>             is = new FileInputStream(new File("nonexist"));
>>         }catch(Exception e){
>>             System.gc();
>>             e.printStackTrace();
>>         }
>>     }
>> }
>>
>>
>>
>>
>> -- 
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>>    http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>>    http://www.atlassian.com/software/jira
>>
>>
>
>


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by Tim Ellison <t....@gmail.com>.
FYI exceptions thrown during a finalize method end the execution of that
method, but otherwise are ignored by the finalizer.

Regards,
Tim

Paulex Yang wrote:
> Gregory,
> 
> Sorry I response so late. I just back from a long vacation and it took
> me longer time than I expected to catch up the mailing list (after all,
> it's very active!). Please see my comments below.
> 
> Gregory Shimansky wrote:
>> Hello Paulex
>>
>> I have a question about this problem. Do you know how exception in
>> finalizer
>> method affects the finalizer thread that it becomes suspended? I thought
>> that when calling finalize method the code should catch all exceptions
>> thrown by it and ignore them. AFAIK that's how finalizers are
>> implemented in
>> DRLVM. It specification it is written that
> First of all, I think this issue should not happen if the spec of
> FileInputStream/OutputStream doesn't require the implementation to
> invoke close() in finalize() method, IMHO, generally it's not good
> practice to depend on finalize(), and I guess this spec is inherited
> from very early version, say, JDK 1.0, when the channel hasn't been not
> introduced.
> 
> And actually I don't know exactly what happened to the finalizer thread
> when the NullPointerException thrown, because, as you know, the Harmony
> VME provided by IBM is only binary. What I saw is that the debugger
> sometimes stops on the suspending finalizer thread at the
> FileInputStream/OutputStream's close(), and the message shows that
> "NullPointerException caused suspending"(maybe not exact words, but very
> similar). So I tried to fix this problem in Java codes.
> 
> And I'd glad to have a try on DRLVM later, but anyway,  I think it is
> not bad idea to make our classlib codes more defensive and reliable.
> your ideas?
>>
>> "If an uncaught exception is thrown by the finalize method, the
>> exception is
>> ignored and finalization of that object terminates."
>>
>> 2006/5/19, Paulex Yang (JIRA) <ji...@apache.org>:
>>>
>>> java.io.FileInputStream and FileOutputStream might cause Finalizer
>>> thread
>>> suspending
>>>
>>> ------------------------------------------------------------------------------------
>>>
>>>
>>>          Key: HARMONY-479
>>>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>>>      Project: Harmony
>>>         Type: Bug
>>>
>>>   Components: Classlib
>>>     Reporter: Paulex Yang
>>>
>>>
>>> If one FileInputStream instance is not constructed properly, say, the
>>> given file doesn't exist, the constructor will throw exception but the
>>> FileInputStream instance is still necessary to be garbage collected,
>>> and the
>>> spec of FileInputStream's finalize() method requires that close()
>>> must be
>>> invoked, but the current implementation of FileInputStream.close()(as
>>> below) will causes NullPointerException in Finalizer thread because
>>> channel
>>> field has not been initialized yet.
>>>
>>>     public void close() throws IOException {
>>>             synchronized (channel) {
>>>                 synchronized (this) {
>>>                     if (channel.isOpen() && fd.descriptor >= 0) {
>>>                         channel.close();
>>>                     }
>>>                     fd.descriptor = -1;
>>>                 }
>>>             }
>>>     }
>>>
>>> This issue applies to FileOutputStream, too. Test case below can
>>> reproduce
>>> this issue only in debugger, because it is not easy to get the handle of
>>> Finalizer thread. Debugging the test case to the statement following the
>>> System.gc(), the debugger will show that the Finalizer thread is
>>> suspended
>>> due to NullPointerException.
>>>
>>>
>>> public class FileInputStreamTest {
>>>     public static void main(String[] args) throws Exception{
>>>         FileInputStream is = null;
>>>         try{
>>>             is = new FileInputStream(new File("nonexist"));
>>>         }catch(Exception e){
>>>             System.gc();
>>>             e.printStackTrace();
>>>         }
>>>     }
>>> }
>>>
>>>
>>>
>>>
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators:
>>>    http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
>>>    http://www.atlassian.com/software/jira
>>>
>>>
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by Gregory Shimansky <gs...@gmail.com>.
Hello Paulex

I have no objections against your changes. A check is always cheaper than
exception.

I just wondered how a user code such as finalizer can affect VM like that,
nothing more.

2006/5/23, Paulex Yang <pa...@gmail.com>:
>
> > I have a question about this problem. Do you know how exception in
> > finalizer
> > method affects the finalizer thread that it becomes suspended? I thought
> > that when calling finalize method the code should catch all exceptions
> > thrown by it and ignore them. AFAIK that's how finalizers are
> > implemented in
> > DRLVM. It specification it is written that
> First of all, I think this issue should not happen if the spec of
> FileInputStream/OutputStream doesn't require the implementation to
> invoke close() in finalize() method, IMHO, generally it's not good
> practice to depend on finalize(), and I guess this spec is inherited
> from very early version, say, JDK 1.0, when the channel hasn't been not
> introduced.
>
> And actually I don't know exactly what happened to the finalizer thread
> when the NullPointerException thrown, because, as you know, the Harmony
> VME provided by IBM is only binary. What I saw is that the debugger
> sometimes stops on the suspending finalizer thread at the
> FileInputStream/OutputStream's close(), and the message shows that
> "NullPointerException caused suspending"(maybe not exact words, but very
> similar). So I tried to fix this problem in Java codes.
>
> And I'd glad to have a try on DRLVM later, but anyway,  I think it is
> not bad idea to make our classlib codes more defensive and reliable.
> your ideas?
>
-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by Paulex Yang <pa...@gmail.com>.
Gregory,

Sorry I response so late. I just back from a long vacation and it took 
me longer time than I expected to catch up the mailing list (after all, 
it's very active!). Please see my comments below.

Gregory Shimansky wrote:
> Hello Paulex
>
> I have a question about this problem. Do you know how exception in 
> finalizer
> method affects the finalizer thread that it becomes suspended? I thought
> that when calling finalize method the code should catch all exceptions
> thrown by it and ignore them. AFAIK that's how finalizers are 
> implemented in
> DRLVM. It specification it is written that
First of all, I think this issue should not happen if the spec of 
FileInputStream/OutputStream doesn't require the implementation to 
invoke close() in finalize() method, IMHO, generally it's not good 
practice to depend on finalize(), and I guess this spec is inherited 
from very early version, say, JDK 1.0, when the channel hasn't been not 
introduced.

And actually I don't know exactly what happened to the finalizer thread 
when the NullPointerException thrown, because, as you know, the Harmony 
VME provided by IBM is only binary. What I saw is that the debugger 
sometimes stops on the suspending finalizer thread at the 
FileInputStream/OutputStream's close(), and the message shows that 
"NullPointerException caused suspending"(maybe not exact words, but very 
similar). So I tried to fix this problem in Java codes.

And I'd glad to have a try on DRLVM later, but anyway,  I think it is 
not bad idea to make our classlib codes more defensive and reliable. 
your ideas?
>
> "If an uncaught exception is thrown by the finalize method, the 
> exception is
> ignored and finalization of that object terminates."
>
> 2006/5/19, Paulex Yang (JIRA) <ji...@apache.org>:
>>
>> java.io.FileInputStream and FileOutputStream might cause Finalizer 
>> thread
>> suspending
>>
>> ------------------------------------------------------------------------------------ 
>>
>>
>>          Key: HARMONY-479
>>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>>      Project: Harmony
>>         Type: Bug
>>
>>   Components: Classlib
>>     Reporter: Paulex Yang
>>
>>
>> If one FileInputStream instance is not constructed properly, say, the
>> given file doesn't exist, the constructor will throw exception but the
>> FileInputStream instance is still necessary to be garbage collected, 
>> and the
>> spec of FileInputStream's finalize() method requires that close() 
>> must be
>> invoked, but the current implementation of FileInputStream.close()(as
>> below) will causes NullPointerException in Finalizer thread because 
>> channel
>> field has not been initialized yet.
>>
>>     public void close() throws IOException {
>>             synchronized (channel) {
>>                 synchronized (this) {
>>                     if (channel.isOpen() && fd.descriptor >= 0) {
>>                         channel.close();
>>                     }
>>                     fd.descriptor = -1;
>>                 }
>>             }
>>     }
>>
>> This issue applies to FileOutputStream, too. Test case below can 
>> reproduce
>> this issue only in debugger, because it is not easy to get the handle of
>> Finalizer thread. Debugging the test case to the statement following the
>> System.gc(), the debugger will show that the Finalizer thread is 
>> suspended
>> due to NullPointerException.
>>
>>
>> public class FileInputStreamTest {
>>     public static void main(String[] args) throws Exception{
>>         FileInputStream is = null;
>>         try{
>>             is = new FileInputStream(new File("nonexist"));
>>         }catch(Exception e){
>>             System.gc();
>>             e.printStackTrace();
>>         }
>>     }
>> }
>>
>>
>>
>>
>> -- 
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>>    http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>>    http://www.atlassian.com/software/jira
>>
>>
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by Gregory Shimansky <gs...@gmail.com>.
Hello Paulex

I have a question about this problem. Do you know how exception in finalizer
method affects the finalizer thread that it becomes suspended? I thought
that when calling finalize method the code should catch all exceptions
thrown by it and ignore them. AFAIK that's how finalizers are implemented in
DRLVM. It specification it is written that

"If an uncaught exception is thrown by the finalize method, the exception is
ignored and finalization of that object terminates."

2006/5/19, Paulex Yang (JIRA) <ji...@apache.org>:
>
> java.io.FileInputStream and FileOutputStream might cause Finalizer thread
> suspending
>
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug
>
>   Components: Classlib
>     Reporter: Paulex Yang
>
>
> If one FileInputStream instance is not constructed properly, say, the
> given file doesn't exist, the constructor will throw exception but the
> FileInputStream instance is still necessary to be garbage collected, and the
> spec of FileInputStream's finalize() method requires that close() must be
> invoked, but the current implementation of FileInputStream.close()(as
> below) will causes NullPointerException in Finalizer thread because channel
> field has not been initialized yet.
>
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
>
> This issue applies to FileOutputStream, too. Test case below can reproduce
> this issue only in debugger, because it is not easy to get the handle of
> Finalizer thread. Debugging the test case to the statement following the
> System.gc(), the debugger will show that the Finalizer thread is suspended
> due to NullPointerException.
>
>
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }
>
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira
>
>


-- 
Gregory Shimansky, Intel Middleware Products Division

[jira] Commented: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by "Paulex Yang (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/HARMONY-479?page=comments#action_12412726 ] 

Paulex Yang commented on HARMONY-479:
-------------------------------------

looks fine, thank you, George.

> java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>     Assignee: George Harley
>  Attachments: Harmony-479.diff
>
> If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
> This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Closed: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by "George Harley (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-479?page=all ]
     
George Harley closed HARMONY-479:
---------------------------------


Verified by Paulex. 

> java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>     Assignee: George Harley
>  Attachments: Harmony-479.diff
>
> If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
> This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Updated: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by "Paulex Yang (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-479?page=all ]

Paulex Yang updated HARMONY-479:
--------------------------------

    Attachment: Harmony-479.diff

Please try this patch.  I'm sorry but I have no idea how to write regression test except by leveraging debugger, so I only attached patch for implementation. 

> java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>  Attachments: Harmony-479.diff
>
> If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
> This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Assigned: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by "George Harley (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-479?page=all ]

George Harley reassigned HARMONY-479:
-------------------------------------

    Assign To: George Harley

> java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>     Assignee: George Harley
>  Attachments: Harmony-479.diff
>
> If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
> This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Resolved: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending

Posted by "George Harley (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/HARMONY-479?page=all ]
     
George Harley resolved HARMONY-479:
-----------------------------------

    Resolution: Fixed

Hi Paulex, 

Patch committed in revision 407775. Please could you verify that it has been applied as expected. 

Many thanks for this enhancement. 

Best regards, 
George

> java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
> ------------------------------------------------------------------------------------
>
>          Key: HARMONY-479
>          URL: http://issues.apache.org/jira/browse/HARMONY-479
>      Project: Harmony
>         Type: Bug

>   Components: Classlib
>     Reporter: Paulex Yang
>     Assignee: George Harley
>  Attachments: Harmony-479.diff
>
> If one FileInputStream instance is not constructed properly, say, the given file doesn't exist, the constructor will throw exception but the FileInputStream instance is still necessary to be garbage collected, and the spec of FileInputStream's finalize() method requires that close() must be invoked, but the current implementation of FileInputStream.close()(as below) will causes NullPointerException in Finalizer thread because channel field has not been initialized yet.
>     public void close() throws IOException {
>             synchronized (channel) {
>                 synchronized (this) {
>                     if (channel.isOpen() && fd.descriptor >= 0) {
>                         channel.close();
>                     }
>                     fd.descriptor = -1;
>                 }
>             }
>     }
> This issue applies to FileOutputStream, too. Test case below can reproduce this issue only in debugger, because it is not easy to get the handle of Finalizer thread. Debugging the test case to the statement following the System.gc(), the debugger will show that the Finalizer thread is suspended due to NullPointerException.
> public class FileInputStreamTest {
>     public static void main(String[] args) throws Exception{
>         FileInputStream is = null;
>         try{
>             is = new FileInputStream(new File("nonexist"));
>         }catch(Exception e){
>             System.gc();
>             e.printStackTrace();
>         }
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira