Here's a patch you should consider for mono-2.6.1. Specifically, I noticed
that /dev/shm/mono.pid files were piling up and not being cleaned up as they
should have been. mono-mmap.c tries to get rid of stale ones with a kill but
they don't check for ENOMEM return which causes the cleanup to fail.
Is there a document that describes the x86 pseudo code your JIT engine uses.
For example, it would be a lot easier for me to find bugs for you if I
didn't have to reverse-engineer things such as:
Thanks,
Cal Page
if ( 0 && mono_thread_get_tls_offset () != -1) {
/* MonoOb
The shared memory files are created in /dev/shm/... on linux, but the code
tries to find them in your home account. Since the file doesn't exist, a 0
is returned from ftok. This results in a pileup of shm's and semaphores. Run
ipcs -a after every run to see the probmem.
Cal Page
Here's the pat
My Visual Studio 2005 throws the exception.
Specifically, what version of the .net frawmwork do you support? If it 1.1,
then I can see your point, but 2.0 and beyond, the mono code should do the
exception.
Cal Page
--
View this message in context:
http://n4.nabble.com/System-Threading-Monitor
According to the 2.0 .net MS spec, an exception is thrown for
System.Threading.Monitor . From them:
Exceptions
Exception type Condition
ArgumentNullException
The obj parameter is a null reference (Nothing in Visual Basic).
SynchronizationLockException
The current thread d
I never get a signal when System.Threading.Monitor::Exit gets called too many
times. Further, I traced it down into the mono 2.6.1 code tree, and
mono_monitor_exit is never called. The trampoline generates the code, but
it's never called. Can you provide a quick fix? It seems like a glaring bug.
A
Here's a compile error from 2.6.1 and your latest svn tree:
CC io.lo
In file included from ../../mono/io-layer/wapi.h:28,
from io.c:32:
../../mono/io-layer/sockets.h:85: error: conflicting types for ‘close’
/usr/include/unistd.h:350: note: previous declaration of ‘close’ was
Here's a patch you should consider for mono-2.6.1. Specifically, I noticed
that /dev/shm/mono.pid files were piling up and not being cleaned up as they
should have been. mono-mmap.c tries to get rid of stale ones with a kill but
they don't check for ENOMEM return which causes the cleanup to fail.
