[Mono-dev] SafeFileHandle

Greg Young gregoryyoung1 at gmail.com
Mon Jan 12 22:58:27 UTC 2015


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


More information about the Mono-devel-list mailing list