I have installed mono version 4.2.1.60 on my CentOS operating system from this source by first downloading the tarball and then doing sudo ./configure, sudo make and sudo make install on the extracted source files.
Configure return this, which looks ok to me
Engine:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
GC: sgen and Included Boehm GC with typed GC and parallel mark
TLS: __thread
SIGALTSTACK: yes
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Mono itself runs fine this way with the major collector marksweep.
But now I want to run mono with the SGen garbage collector and it's major collector marksweep-par for some tests. This is what I do according to this description:
export MONO_GC_PARAMS=major=marksweep-par
mono-sgen testApp.exe
Unfortunately mono starts with this warning
Warning: In environment variable 'MONO_GC_PARAMS': Unknown major collector 'marksweep-par'. - Using 'marksweep' instead.
Of course this is not what I want. Google did not return an answer to me when looking for this warning. Now my question is, how I can get mono to run with marksweep-par.
What am I doing wrong? Any help is appreciated.
You are referring to a old man page (Mono 2.5) while you are running 4.2+.
You should review the man page installed on your system:
man mono
major=collector
Specifies which major collector to use. Options are marksweep for
the Mark&Sweep collector, and marksweep-conc for concurrent
Mark&Sweep. The non-concurrent Mark&Sweep collector is the default.
Related
I have a Mono application running under Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1.1) with --debug enabled. After quiet some time, I get quiet unexpected memory usage.
I know there is HeapShot but it generates over 4GB of output even before the problem gets real. In addition the UI tool can not load more than ~17 of the included Snapshots before running out of memory while loading the Dump.
That's why I'm looking for a way to produce a single Heap dump of my application when the memory usage grew big. Is there any way?
An alternative would be to get better tooling to load single snapshots from a huge generated HeapShot dump.
Any hints how to find the memory leak would be helpful, too.
Thanks.
run in first terminal, it will not produce dump until command "heapshot" sent
mono --debug --profile=log:heapshot,heapshot=ondemand,time=fast,port=7103,output=%p.mlpd MyApp.exe
to obtain heapshot ondemand run in second terminal to send command "heapshot"
echo -n "heapshot\n" | nc localhost 7103
You need to install netcat package from your distro
I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()
Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.
This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.
I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?
I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account
Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.
we are currently having serious problems running a pure c# application on mono 2.8.1 on debian 5.
We are using .net webservices as well as async sockets and probably found a race condition in the mono threadpool.
I would be thankful for every idea.
if someone has informations if mono 2.8.1 has known problems on debian 4/5 that might have something to do with this, please answer too:)
Assertion at mono-wsq.c:73, condition `mono_wsq_count (wsq) == 0' not met
Stacktrace:
Native stacktrace:
mono [0x48f582]
/lib/libpthread.so.0 [0x2abe8f8d2a80]
/lib/libc.so.6(gsignal+0x35) [0x2abe8fb12ed5]
/lib/libc.so.6(abort+0x183) [0x2abe8fb143f3]
mono [0x5cd042]
mono [0x5cd21a]
mono [0x5f271a]
mono [0x5924ca]
mono [0x58c24b]
mono [0x5bd83b]
mono [0x5e9ed6]
/lib/libpthread.so.0 [0x2abe8f8cafc7]
/lib/libc.so.6(clone+0x6d) [0x2abe8fbb064d]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
I fixed this in mono 2.8.2. Someone has reported that they still see it in 2.8.2 (we don't see it in our servers any more) and we are working to debug it.
I have a file called hellowf.cs
class MyFirstApp {
static void Main() {
System.Windows.Forms.MessageBox.Show("Hello, Mono+WinForms!");
}
}
On Ubuntu 8.10, I do the following
gmcs hellowf.cs -r:System.Drawing.dll -r:System.Windows.Forms.dll
mono hellowf.exe
... and it looks like this:
alt text http://img136.imageshack.us/img136/4674/helloproblemuk5.png
The second part of the message is missing. Why is this happening? The same binary - hellowf.exe - works fine on Windows.
Update:
This is really annoying. Here are the mono versions I have had and tried to make this work on so far:
1.9.1 (from official ubuntu repo)
2.0.1 (from some some 3rd party repo)
2.2 (wiped every mono pkg and compiled myself)
My Current mono version:
mono --version
Mono JIT compiler version 2.2 (tarball Wed Jan 14 22:58:21 CET 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
gmcs --version
Mono C# compiler version 2.2.0.0
... any clues?
Finally I have found a workaround. This seems to be a bug in Mono related to font rendering. It happens when "Full" hinting is turned on. I usually have it that way. Changing it to "Slight" or "Medium" in System->Preferences->Appearance->Fonts->Details fixes the problem. Thanks for the help!
Works OK on opensuse 11.0, mono 2.0.1.
Please, edit your question and put the mono version you are using.
stick an # in front of the "Hello, Mono+WinForms!" and see if it still happens.
Standard debugging advice:
Start making small, controlled changes, and see what happens.
This will help narrow down what the problem is.
Try removing the symbols: , + !
Try removing the space.
Try a variety of shorter strings, and possibly some longer strings.
Once you have a better idea of what the MessageBox will and will not print, you can start to debug that specific problem, instead of trying to debug, "It doesn't work!"
When you updated your packages and source code, did you update/compile libgdiplus? We have seen some funky graphical problems if the System.Drawing and libgdiplus versions get out of sync.