System.NotSupportedException: Stream does not support writing

[Corax]

Client hangs after a while (apparently does not recover from saving the world, if that isn't pure irony, I don't know what is... ). Can be terminated with CTRL-C when launched from shell prompt.

 

System info:

Quote

$ inxi -b
System:    Host: apollo Kernel: 4.19.0-gentoo x86_64 bits: 64 Desktop: Xfce 4.12.4
           Distro: Gentoo Base System release 2.4.1
Machine:   Type: Desktop Mobo: ASUSTeK model: PRIME B350M-A v: Rev X.0x serial: <root required>
           UEFI [Legacy]: American Megatrends v: 4011 date: 04/19/2018
CPU:       8-Core: AMD Ryzen 7 1800X type: MT MCP speed: 1882 MHz min/max: 2200/3600 MHz
Graphics:  Card-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] driver: amdgpu
           v: kernel
           Display: server: X.Org 1.20.3 driver: amdgpu,ati unloaded: modesetting resolution: 1920x1200~60Hz
           OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM 3.27.0 4.19.0-gentoo LLVM 6.0.1)
           v: 4.5 Mesa 18.2.2
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives:    Local Storage: total: 4.09 TiB used: 3.76 TiB (92.0%)
Info:      Processes: 288 Uptime: 19h 22m Memory: 31.41 GiB used: 3.22 GiB (10.3%) Shell: bash inxi: 3.0.20
 

 

client-crash.txt

client-main.txt.gz

[Tyron]

Hm, strange. It crashes when it tries to set the foreground color of the console (for a warning or an error). Is it maybe trying to write to a kind of shell that does not support colors?

Either way, i'll surround that part with a try{}catch so that it just ignores any error that may occur while trying to set it. Will be in v1.7.9.

Thanks for the report

[Corax]

It seems the stream writing exception only occurs if/when the client is stopped directly from the console it is running in using CTRL-C, regardless of whether it has crashed or not. Killing it from another terminal ( 'kill -9 $(pidof mono)' ) causes it to terminate without throwing an exception.

The actual crash has to happen somewhere else entirely, and it doesn't seem to leave any trace in the logs; spending much effort in tracking down that write exception is likely following a false trail.