• Version: Mono JIT compiler version 5.11.0 (master/2b90049bcce Mon Dec 11 17:05:00 AST 2017)
  Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
  TLS: normal
  SIGSEGV: normal
  Notification: Thread + polling
  Architecture: amd64
  Disabled: none
  Misc: softdebug
  Interpreter: yes
  LLVM: supported, not enabled.
  GC: sgen
• Platform: Haiku shredder 1 hrev51662 Dec 8 2017 18:40:07 x86_64 x86_64 Haiku [x86 is affected too]
• Subsystem: mono/utils/mono-threads.c

The function suspend_sync_nolock causes an infinite loop after the program terminates and runtime cleanup is performed, For some reason, the conditions that break the loop (related to threading) are not met, and the sleep duration raises infinitely making any chance of breaking out of the loop increasingly unlikely.

To fix, the cause of the loop being unbroken must be found. (It may be prudent to just give up on the loop after a while too.) I'm uncertain if the problem is within Mono or Haiku either; I'm leaning towards Mono, which is why I'm filing here.

(NOTE: When debugging, I had to make this function non-static so I could set breakpoints properly on the function body, or Haiku's debugger was unaware of it. You can make the makefiles start Mono attached to the debugger by prefixing the mono executable name in runtime/mono-wrapper with "Debugger ".) (ALSO NOTE: If you want to reproduce this yourself, the build dependencies needed for Mono on Haiku are gettext and libtool. Note on x86 you will have to run setarch x86 to get GCC5.)

If this bug is fixed, then Roslyn should be able to successfully terminate and we may be able to successfully build the managed parts of Mono for a working Haiku build.