Help:Toolforge/Mono

Toolforge
Toolforge technical documentation Toolforge administrator documentation Help and communication List of tools Terms and conditions Glossary Technical documentation resources
Getting started Cloud VPS and Toolforge at a glance About Toolforge Toolforge quickstart guide How-tos, tutorials and walkthroughs Create a Wikimedia developer account Access Toolforge instances with PuTTY and WinSCP Troubleshooting Toolforge
Developing tools Tool accounts Developing successful tools Develop Mono/.NET tools and bots Develop tools in Java Develop tools in Python Develop tools using Pywikibot framework Web servers for tools (Kubernetes) Grid engine
Additional documentation Version control in Toolforge Elasticsearch for Toolforge Redis for Toolforge Dumps and Toolforge Database

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://tools.wmflabs.org/admin/oge/status)
• 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.