Installation of mono-devel fails at specific step on new Debian 9 system

[hjmuller]

Steps to Reproduce

1. Install new Debian 9 system
2. Update to all latest packages on stable Debian 9 branch
3. Add Mono repo
4. Install mono-devel using apt-get. Notice it hangs on this step:
   Mono precompiling /usr/lib/mono/4.5/Microsoft.CodeAnalysis.CSharp.dll for amd64...

Current Behavior

Currently mono-devel installation cannot complete. It hangs at the aforementioned step.

Expected Behavior

Expect mono-devel to install successfully without issue.

On which platforms did you notice this

[ ] macOS
[X] Linux (fresh Debian 9 system)
[ ] Windows

Version Used:

Attempting to install latest stable version

Stacktrace

Please paste the stack trace here if available.

[lewurm]

Do you see a mono process running? If yes, could you gdb -p $PID and then in gdb do thread apply all bt and paste the output here (or to gist.github.com)? Thanks!

[hjmuller]

For the "mono" process:

root@tst-ct-testserver:~# gdb -p 5683
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 5683
[New LWP 5684]
[New LWP 5685]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fb1dea8004a in __GI___waitpid (pid=5688, stat_loc=stat_loc@entry=0x7ffe7a08c6d0, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
29      ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) thread apply all bt

Thread 3 (Thread 0x7fb1dc387700 (LWP 5685)):
#0  0x00007fb1def8d536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5560df97fa60) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x5560df97fa60, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007fb1def8d5e4 in __new_sem_wait_slow (sem=0x5560df97fa60, abstime=0x0) at sem_waitcommon.c:181
#3  0x00005560df5b4f8e in ?? ()
#4  0x00005560df56c7d5 in ?? ()
#5  0x00007fb1def85494 in start_thread (arg=0x7fb1dc387700) at pthread_create.c:333
#6  0x00007fb1deab0acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fb1de3ff700 (LWP 5684)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00005560df61caeb in ?? ()
#2  0x00007fb1def85494 in start_thread (arg=0x7fb1de3ff700) at pthread_create.c:333
#3  0x00007fb1deab0acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x7fb1dfac0740 (LWP 5683)):
#0  0x00007fb1dea8004a in __GI___waitpid (pid=5688, stat_loc=stat_loc@entry=0x7ffe7a08c6d0, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1  0x00007fb1dea070ab in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:148
#2  0x00005560df3cd714 in ?? ()
#3  0x00005560df3df7a7 in ?? ()
#4  0x00005560df3c38a4 in mono_main ()
#5  0x00005560df36e74c in ?? ()
#6  0x00007fb1de9e82e1 in __libc_start_main (main=0x5560df36e630, argc=4, argv=0x7ffe7a08d1d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe7a08d1c8)
    at ../csu/libc-start.c:291
#7  0x00005560df36ee9a in _start ()
(gdb)

I also tried to attach to the "mono-roslyn.pos" process, but it seems to hang the system with no further output.

[lewurm]

that looks weird. what is the output of cat /proc/$PID/cmdline?

[hjmuller]

The installation actually just finished without error. It seems like it does take a very long time to complete, but it did finish.

I'll close this since it doesn't seem like an error.

[awb99]

I have the same behavior on a brand new hosted debian 9 server:
It is compiling for an hour now, and it seems completely stuck.

Mono precompiling /usr/lib/mono/4.5/csc.exe for amd64 (trying with LLVM)...
Mono precompiling /usr/lib/mono/4.5/vbc.exe for amd64 (trying with LLVM)...
Mono precompiling /usr/lib/mono/4.5/VBCSCompiler.exe for amd64 (trying with LLVM)...
Mono precompiling /usr/lib/mono/4.5/Microsoft.CodeAnalysis.CSharp.dll for amd64 (trying with LLVM)...


Progress: [ 92%] [#########################################################################################################################################............] 

Update: Compilation took 1 hour 20 minutes!! But it worked finally. I still think there must be a bug
somewhere, it canot take that long to compile.

[Reelix]

https://i.imgur.com/pkvYnzU.png

Came across this thread whilst waiting for that. 16 hours later it still hasn't moved. This should definately not be marked as closed if it's current status is "It may take an indefinite amount of time with no visible output or any way to see if it has crashed or not"

I recommend that this issue be re-opened until there is a better solution. "It may take a minute, an hour, a month, or it may have crashed - Just wait" is not a viable resolution.

[azamat-commits]

On Ubuntu 18.04 with it stuck on mentioned step for about 20 minutes, and eventually completed.

[HexedHero]

Same issue here on Ubuntu 18.04, it hangs forever it seems.

[MildlyInterested]

Had the same happening on Lubuntu 19.04. Worked once I upped the ram to 4GB and two cpu cores.

[glenngillen]

Ended up here due to the same hanging problem while repeatedly building an image on AWS using a t2.micro. Following the recommendation from @MildlyInterested I upped it to a t3.micro and the step that was hanging then took < 30secs to progress.

[ghost]

+1

[C0rn3j]

This is not helped by the fact that the precompilation is done on a single thread, however it seems that the thread option for --aot is unfortunately experimental...

--aot
  threads=[number]
       This is an experimental option for the AOT compiler to use multiple threads when compiling the methods.

[JM-AIV]

I can confirm this behavior on Debian 10 on a Rasberry Pi 3+

Mono precompiling /usr/lib/mono/4.5/Microsoft.CodeAnalysis.CSharp.dll for arm (LLVM disabled due to missing SSE4.1)...

stuck for atleast 1 hour right now...