Bug 58738 - System.IO.MonoIO.Read - Native Crash when device file is gone
Summary: System.IO.MonoIO.Read - Native Crash when device file is gone
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer (show other bugs)
Version: master
Hardware: Other Linux
: --- normal
Target Milestone: ---
Assignee: Bernhard Urban
URL:
Depends on:
Blocks:
 
Reported: 2017-08-13 04:20 UTC by Dominik Schmidt
Modified: 2017-10-19 19:35 UTC (History)
5 users (show)

Tags: bugpool-archive
Is this bug a regression?: ---
Last known good build:


Attachments
Native Crash Info (8.96 KB, text/plain)
2017-08-13 04:20 UTC, Dominik Schmidt
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Dominik Schmidt 2017-08-13 04:20:34 UTC
Created attachment 24156 [details]
Native Crash Info

Hi !

I have an Bluetooth attached PS3 Controller on my Raspberry Pi and read the information over the device file /dev/input/js0 (http://mpolaczyk.pl/raspberry-pi-mono-c-joystick-handler/). This works awesome. 
Anyway ... If I switch off the PS3 Controller the device file is gone. The read operation produces a native Crash (see attached file). 

I tried to catch the error with this try block... 
                try
                {
                    fs.Read(buff, 0, 8);
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.Message);
                }
But that won´t work. 

I suppose there is something missing or buggy in the System.IO.MonoIO.Read Methode. 

would be great if anyone can check and fix this. 

regards
  Dominik
Comment 1 Ludovic Henry 2017-08-16 16:43:09 UTC
https://github.com/mono/mono/pull/5385
Comment 2 Ludovic Henry 2017-08-17 17:13:28 UTC
This is fixed on master with https://github.com/mono/mono/commit/91288cad6a6c093ee1ca9b072219144c8bac9f75

It is being backported to 5.4 and 5.6 at https://github.com/mono/mono/pull/5392 and https://github.com/mono/mono/pull/5391 respectively.
Comment 3 Dominik Schmidt 2017-08-22 13:19:04 UTC
Hi !

Is this fixed in Mono JIT compiler version 5.4.0.135? 

I have installed that on my Raspberry Pi and still get the native crash. 

regards
   Dominik
Comment 4 Dominik Schmidt 2017-08-24 02:28:43 UTC
Hi !

today there way a new Mono release "Mono JIT compiler version 5.4.0.167 (tarball Wed Aug 23 22:14:50 UTC 2017)". But even with that version I get the native crash. 

So is this really fixed ? 

Beginning of the crash: 
w32error-unix.c: unknown error (19) "No such device"
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.IO.MonoIO.Read (intptr,byte[],int,int,System.IO.MonoIOError&) <0x0004b>
  at System.IO.MonoIO.Read (System.Runtime.InteropServices.SafeHandle,byte[],int,int,System.IO.MonoIOError&) [0x00010] in <f4ce43f1d0d745dcb3e5329cb606b5f0>:0
  at System.IO.FileStream.ReadData (System.Runtime.InteropServices.SafeHandle,byte[],int,int) [0x00002] in <f4ce43f1d0d745dcb3e5329cb606b5f0>:0
  at System.IO.FileStream.RefillBuffer () [0x00006] in <f4ce43f1d0d745dcb3e5329cb606b5f0>:0
  at System.IO.FileStream.ReadInternal (byte[],int,int) [0x00049] in <f4ce43f1d0d745dcb3e5329cb606b5f0>:0
  at System.IO.FileStream.Read (byte[],int,int) [0x000a1] in <f4ce43f1d0d745dcb3e5329cb606b5f0>:0
  at Program.Main (string[]) [0x0009c] in <38943faadac240dcb1e0ef1688edd392>:0
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x0004e] in <38943faadac240dcb1e0ef1688edd392>:0
/proc/self/maps:
00010000-00337000 r-xp 00000000 b3:02 49447      /usr/bin/mono-sgen
00346000-00347000 r--p 00326000 b3:02 49447      /usr/bin/mono-sgen
00347000-00349000 rw-p 00327000 b3:02 49447      /usr/bin/mono-sgen
00349000-00375000 rw-p 00000000 00:00 0
.....

regards 
  Dominik
Comment 5 Bernhard Urban 2017-09-15 09:15:37 UTC
works for me on mono/master:

> Unhandled Exception:
> System.IO.IOException: Win32 IO returned 55. Path: /dev/input/js2
>   at System.IO.FileStream.ReadData (System.Runtime.InteropServices.SafeHandle safeHandle, System.Byte[] buf, System.Int32 offset, System.Int32 count) [0x00038] in /home/lewurm/work/mono/mcs/class/corlib/System.IO/FileStream.cs:1079
>   at System.IO.FileStream.RefillBuffer () [0x00006] in /home/lewurm/work/mono/mcs/class/corlib/System.IO/FileStream.cs:1055
>   at System.IO.FileStream.ReadInternal (System.Byte[] dest, System.Int32 offset, System.Int32 count) [0x00049] in /home/lewurm/work/mono/mcs/class/corlib/System.IO/FileStream.cs:535
>   at System.IO.FileStream.Read (System.Byte[] array, System.Int32 offset, System.Int32 count) [0x000a1] in /home/lewurm/work/mono/mcs/class/corlib/System.IO/FileStream.cs:510
>   at Program.Main (System.String[] args) [0x00049] in /home/lewurm/work/mono/mono/jstest-mono.cs:19

can you try with the latest 5.4? I mark it as fixed for now, please reopen if you still have any problems.

By the way, I added a translation of the error code if the device path doesn't exist: https://github.com/mono/mono/pull/5588
Comment 6 Dominik Schmidt 2017-09-15 09:22:53 UTC
Hi Bernhard, 

sure I can test it. But which 5.4 version did you use exactely? 
I installed the version 5.4.0.167 from the alpha Xamarin repository.
Or is that version to old? 

regards Dominik
Comment 7 Bernhard Urban 2017-09-15 11:10:29 UTC
Hey Dominik,

5.4.0.167 is indeed the latest 5.4 build available. Alas, it doesn't contain the fix yet. You either have to build it yourself from source or wait for the next build (can't give you an ETA for that, sorry).

-Bernhard