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 <[email protected]> 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 <[email protected]> wrote: >> Hi, >> >> Yes, please file a report. >> >> Zoltan >> >> On Mon, Jan 12, 2015 at 5:42 PM, Greg Young <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> > 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 >>> >> [email protected] >>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> > >>> > >>> >>> >>> >>> -- >>> Studying for the Turing test >> >> > > > > -- > Studying for the Turing test -- Studying for the Turing test _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
