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
Hi,
Yes, please file a report.
Zoltan
On Mon, Jan 12, 2015 at 5:42 PM, Greg Young 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 ca
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
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 wrote:
> _wapi_handle_unref_full: Attempting to unref unused handle 0x8a
>
> I seem to be getting this mes
_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
Hi
I have some trouble to use a library into my project. The library is
WiimoteLib, and it uses a SafeFileHandle to generate a FileStream to get and
send data to the wiimote. But like I saw on this article :
http://www.mono-project.com/SafeHandles
There is an issue with FileStream when you creat
Hello,
This patch adds an empty constructor to SafeFileHandle so it can be
marshalled as a return value or an out param for pinvokes. If there is an
easy and useful test to write for this in addition to the runtime safehandle
tests, let me know.
Thanks,
Jonathan
safehandle.diff
Description: