1501815629 J * fstd_ ~fstd@x4db56bdc.dyn.telefonica.de
1501815633 Q * fstd Read error: Connection reset by peer
1501815645 N * fstd_ fstd
1501817853 J * fstd_ ~fstd@x4db56bdc.dyn.telefonica.de
1501817853 Q * fstd Read error: Connection reset by peer
1501817854 N * fstd_ fstd
1501826063 Q * Ghislain Ping timeout: 480 seconds
1501826636 Q * sannes Ping timeout: 480 seconds
1501827158 J * sannes ~ace@2a02:fe0:c130:1d90:dd80:1f1:6203:183b
1501830354 J * Ghislain ~ghislain@81.56.195.31
1501835066 Q * dustinm` Quit: Leaving
1501835298 J * dustinm` ~dustinm`@68.ip-149-56-14.net
1501845110 Q * Defaultti Quit: WeeChat .
1501845181 J * Defaultti defaultti@lakka.kapsi.fi
1501847951 Q * CcxWrk Ping timeout: 480 seconds
1501848000 Q * Aiken Remote host closed the connection
1501848629 Q * _are_ Remote host closed the connection
1501848635 J * _are_ ~quassel@2a01:238:4325:ca00:f065:c93c:f967:9285
1501848655 J * CcxWrk ~ccx@asterix.te2000.cz
1501854062 M * [4-tea-2] Uhm, are there known problems with mono in a guest system? If so, is there a workaround, a flag or something that might help? I'm trying to install the "official" mono from mono-project.com on a Debian 8 (jessie) guest and it fails with a SIGSEGV.
1501854150 M * Guy- [4-tea-2]: can you strace the affected process?
1501854252 M * [4-tea-2] Not sure how, since it's happening during the installation process.
1501854287 M * [4-tea-2] mono does provide a stack trace, though. And it seems to say it would love to provide more info if I installed gdb or lldb.
1501854307 M * Bertl_oO yeah, that would be a good start to tracking this down
1501854354 M * Bertl_oO it is unlikely that the guest isolation is the reason for a segfault, but it might be the trigger by exercising an unusual path
1501854438 M * Guy- [4-tea-2]: you can strace the installation process, using something like strace -ffF -s200 -o /tmp/mono.log mono-install-command
1501854460 M * Guy- then look for "Killed by SIGSEGV" oslt in /tmp/mono.log.*
1501854496 M * Bertl_oO for example, if the program tries to raise certain ulimits and doesn't check for success, and simply continues under the assumption that it just worked because 'it always works'
1501854565 M * [4-tea-2] This is the output during the installation process: https://pastebin.com/BBt22PSW
1501854581 M * [4-tea-2] Installing gdb didn't give any additional info.
1501854594 M * [4-tea-2] That's probably not very helpful, is it?
1501854728 M * Bertl_oO you can enable core dumps (by setting the respective ulimit) and then investigate the core dump with gdb
1501854766 M * Bertl_oO but you probably need the debug version of the mono binary for that to make sense
1501854787 M * [4-tea-2] I'm not sure it would make sense TO ME even with debug labels.
1501854793 M * Guy- [4-tea-2]: or try strace -ffF -s200 -o /tmp/mono.log dpkg -i /var/cache/apt/archives/libnunit-core-interfaces2.6.3-cil*
1501854804 M * [4-tea-2] Guy-: on it
1501854836 M * Guy- if that doesn't give anything useful, try ltrace -fS -s200 -o /tmp/mono-ltrace.log dpkg -i /var/cache/apt/archives/libnunit-core-interfaces2.6.3-cil*
1501855011 M * [4-tea-2] Funny story, problem existed between keyboard and chair.
1501855034 M * Guy- pray tell what it was :)
1501855055 M * [4-tea-2] The mono install process dumps a lot of info into /tmp which is a 16MB tmpfs. m(
1501855089 M * Guy- ah
1501855096 M * Guy- and it doesn't do proper error checking, apparently
1501855111 M * [4-tea-2] I noticed when trying the strace to /tmp/mono.log, cleaned up /tmp and on the next attempt the file installed fine.
1501855338 M * Bertl_oO yeah, that's exactly what I meant with 'trigger' :)
1501855349 M * Bertl_oO glad it could be resolved!
1501855384 M * [4-tea-2] Indeed, tyvm, Bertl & Guy!
1501855402 M * Bertl_oO you're welcome!
1501869172 J * Ghislain1 ~ghislain@adsl1.aqueos.com
1501869445 Q * Ghislain Ping timeout: 480 seconds
1501879205 J * Aiken ~Aiken@d63f.h.jbmb.net