Help:Toolforge/Mono
 | This page is currently a draft. More information and discussion about changes to this draft on the talk page. |
This page offers some helps and hints related to developing Mono/.NET tools and bots for Toolforge.
On grid engine
The gridengine nodes contains Mono version 5.x.
Tool fails in grid
Due to the way mono deals with memory allocation it may need a much larger memory limit than its actual memory use. There is no clear error message left from mono indicating this, so if your tool hangs using 99% CPU or have network time out, try to increase the memory limit with -mem. Past tickets include T150099, T186924, & T195834.
At this moment it seems tools may fail without setting at least 1.5gb of memory, so setting -mem 2g is recommended. Luckily mono allocates but does not use this much memory for each job.
Debugging a Mono tool
This happened several times in the past. If the process is running already via normal job submission, an admin could then:
- jump via SSH to the exec node running the job (check https://sge-status.toolforge.org/)
- locate the PID of interest
- open gdb as root (otherwise you can't see other users procs)
- insert gdb macro (src http://www.mono-project.com/docs/debug+profile/debug/):
(gdb) handle SIGXCPU SIG33 SIG35 SIGPWR nostop noprint define mono_stack set $mono_thread = mono_thread_current () if ($mono_thread == 0x00) printf "No mono thread associated with this thread\n" else set $ucp = malloc (sizeof (ucontext_t)) call (void) getcontext ($ucp) call (void) mono_print_thread_dump ($ucp) call (void) free ($ucp) end end
- gdb attach to PID
- if the tool is not redirecting stdout somewhere, you need to do it manually by
(gdb) p close(1)
$1 = 0
(gdb) p creat("/tmp/foo3", 0600)
$2 = 1
- then just call:
(gdb) mono_stack
- and read the stdout file for the stack trace
On kubernetes
Currently, no docker image exists with Mono. This may change in the future.