[Mono-dev] SafeFileHandle

[Greg Young]

Sorry for replying to an old post but it includes the background information.

I am still seeing this behaviour in 4.6.2 but not seeing it in master.
Does anyone happen to know which commits I should be looking at in
regard to this change?

Greg

On Mon, Jan 12, 2015 at 10:58 PM, Greg Young <gregoryyoung1 at gmail.com> wrote:
> Here is the code as well in case you see something obvious. I could
> probably make it smaller but this is pretty simple.
>
> The message happens asynchronously well after the code is run (as you
> can see from the outputs). Causing a gc seems to make it happen sooner
> which made me think finalizer
>
>         [Test]
>         public void shitbird_test() {
>            var filename = GetFilePathFor(Guid.NewGuid().ToString());
>            using(var stream = new shitstream(filename)) {
>                Console.WriteLine(stream.Position);
>            }
>            Console.WriteLine("done");
>         }
>
>     public class shitstream : Stream {
>         private SafeFileHandle _handle;
>
>          public shitstream(string filename) {
>             var han = Syscall.open(filename, OpenFlags.O_CREAT |
> OpenFlags.O_RDONLY, FilePermissions.S_IRWXU);
>             var _handle = new SafeFileHandle((IntPtr) han, true);
>             if(_handle.IsInvalid) throw new Exception("Invalid handle");
>         }
>
>         public override void Flush() {}
>         public override long Seek(long offset, SeekOrigin origin){return 0;}
>
>         public override void SetLength(long value){}
>
>         public override int Read(byte[] buffer, int offset, int count)
> {return 0;}
>         public override void Write(byte[] buffer, int offset, int count) {}
>
>         public override bool CanRead
>         {
>             get { return true; }
>         }
>
>         public override bool CanSeek
>         {
>             get  { return true;}
>         }
>
>         public override bool CanWrite
>         {
>             get { return true; }
>         }
>
>         public override long Length
>         {
>             get  { return 0;}
>         }
>
>         public override long Position
>         {
>             get { return 0;}
>             set  {}
>         }
>
>         protected override void Dispose(bool disposing)
>         {
>             if(_handle == null) return;
>             _handle.Close();
>             _handle = null;
>             GC.SuppressFinalize (this);
>         }
>     }
>
> On Tue, Jan 13, 2015 at 12:46 AM, Zoltan Varga <vargaz at gmail.com> wrote:
>> Hi,
>>
>>   Yes, please file a report.
>>
>>          Zoltan
>>
>> On Mon, Jan 12, 2015 at 5:42 PM, Greg Young <gregoryyoung1 at gmail.com> wrote:
>>>
>>> I have one I can file. I figured it was something on my side though.
>>>
>>> Could it be the FileHandle closing itself later for a second time? Are
>>> there other scenarios aside from close this can happen on?
>>>
>>> In general SafeFileHandle is pretty painful to use since none of the
>>> definitions support it.
>>>
>>> Want me to create an issue?
>>>
>>> Greg
>>>
>>> On Tue, Jan 13, 2015 at 12:32 AM, Zoltan Varga <vargaz at gmail.com> wrote:
>>> > Hi,
>>> >
>>> >   This is a bug, it shouldn't happen. If you have some kind of
>>> > reproducible
>>> > test case, please file a bug report with it.
>>> >
>>> >             Zoltan
>>> >
>>> > On Mon, Jan 12, 2015 at 5:28 PM, Greg Young <gregoryyoung1 at gmail.com>
>>> > wrote:
>>> >>
>>> >> _wapi_handle_unref_full: Attempting to unref unused handle 0x8a
>>> >>
>>> >> I seem to be getting this message from the runtime not sure what could
>>> >> be causing it. From some googling this appears to happen when you
>>> >> close a file handle multiple times.
>>> >>
>>> >> The only place close is called is :
>>> >>
>>> >> protected override void Dispose(bool disposing)
>>> >>         {
>>> >>             if(_handle == null) return;
>>> >>             Flush();
>>> >>             _handle.Close();
>>> >>             _handle = null;
>>> >>            <snip>
>>> >>
>>> >> Not sure how it could be called multiple times. I don't get any issues
>>> >> on the CLR.
>>> >>
>>> >> Any ideas?
>>> >>
>>> >> Greg
>>> >>
>>> >> --
>>> >> Studying for the Turing test
>>> >> _______________________________________________
>>> >> Mono-devel-list mailing list
>>> >> Mono-devel-list at lists.ximian.com
>>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Studying for the Turing test
>>
>>
>
>
>
> --
> Studying for the Turing test



-- 
Studying for the Turing test