[Mono-dev] instruction metadata for xxx inconsistent
I build the source in msvc, the version is 2.8.2. The run time is download from http://www.go-mono.com/mono-downloads/download.html when I run the teste.exe(embeded sample), it output those messages: http://mono.1490590.n4.nabble.com/file/n3243592/teste.png -- View this message in context: http://mono.1490590.n4.nabble.com/instruction-metadata-for-xxx-inconsistent-tp3243592p3243592.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Exception in runtime-invoke Wrapper
Hi Martin, On 27.01.2011 18:15, Martin Däumler wrote: > Hello Robert, > > thank you for your answer! > > On 24.01.2011 18:08, Robert Jordan wrote: > >> You may want to look at how Mono is handling those >> wrappers with its full-AOT subsystem. > > Actually, my pre-compilation code bases on the Full-AOT > code of Mono 2.6.1. Particularly, it uses code of > 'collect_methods()' and 'add_wrappers()'. Instead > of calling 'add_method()' in order to add a chosen > method to the AOT-compile structure, my pre-compilation > code calls 'mono_compile_method()' in order to pre-compile > the method. Quite simple. However, the signature sharing > seems to work not properly for my purposes. In > 'mono_marshal_get_runtime_invoke()' the 'runtime_invoke_cache' > returns one wrapper for different call signature, e.g., > for 'System.Threading.WaitHandle:set_Handle()' and > 'System.Attribute:System.Runtime.InteropServices._Attribute.GetTypeInfoCount()'. Please check if your Mono tree is already containing this patch: https://github.com/mono/mono/commit/901a2d36f9b164ebbb5e4a9753cd817e4e5d26a1 I think w/out this patch, set_Handle(IntPtr) and GetTypeInfoCount(out uint) *might* share a signature. I'm not sure, though. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Incorrect signal handling for Sys V signal handler
Hello, I have other concerns about this use of signal. Perhaps it should be using sigaction with the proper flags to configure how we want signals to be delivered instead. Miguel On Thu, Jan 27, 2011 at 12:52 PM, Jonathan Pryor wrote: > I can't speak to the rest of the patch, but the mono/support patch can't go > in as-is, as mono/support/signal.c is also built for Windows (it's part of > MPH_C_SOURCE in mono/support/Makefile.am, which is included in the HOST_WIN32 > build). > > MSVCRT.DLL DOES contain signal(3); it does NOT contain sigset(3), and thus > this would break the Windows build. > > Furthermore, OSX doesn't provide sigset(3) either, so this would break the > OSX build as well. > > You should patch configure.in to check for sigset, and wrap the sigset calls > with HAVE_SIGSET, otherwise keep the existing signal calls. > > - Jon > > On Jan 27, 2011, at 10:06 AM, Burkhard Linke wrote: > >> Hi, >> >> signal handlers registered with signal(3) behave in a somewhat different way >> for Sys V systems, e.g. Solaris. The manpage states that during the execution >> of the signal handler, the signal disposition is set to SIG_DFL. This raises >> two problems: >> >> a) a possible race condition, if the same signal occurs during the execution >> of its signal handler >> >> b) handling the signal a second time, since the manpage (and the >> implementation under Solaris..) does not reinstall the signal handler. >> >> The attached test program uses Mono.Unix.Signal to catch signals. Executing >> it >> under Solaris/x86 running Mono 2.8.1, Mono 2.6.7 and the git master gives the >> following output: >> >> running as process 29499 >> sending first HUP >> sending second HUP >> Hangup >> >> The second SIGHUP is not catched by the signal handler, terminating the >> application (which is the default for SIGHUP). >> >> The applied patch solves the problem by replacing signal(3) with sigset(3). >> sigset's semantic differs from signal's one; Instead of setting the signal to >> default handling, it adds the signal to the process/threads signal masks, >> executed the signal handler and restores the signal mask. Both problems >> mentioned above are solved. Test program output after applying the patch to >> git master: >> >> running as process 172 >> sending first HUP >> sending second HUP >> sending third HUP >> terminating >> >> >> With best regards, >> Burkhard Linke >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Incorrect signal handling for Sys V signal handler
I can't speak to the rest of the patch, but the mono/support patch can't go in as-is, as mono/support/signal.c is also built for Windows (it's part of MPH_C_SOURCE in mono/support/Makefile.am, which is included in the HOST_WIN32 build). MSVCRT.DLL DOES contain signal(3); it does NOT contain sigset(3), and thus this would break the Windows build. Furthermore, OSX doesn't provide sigset(3) either, so this would break the OSX build as well. You should patch configure.in to check for sigset, and wrap the sigset calls with HAVE_SIGSET, otherwise keep the existing signal calls. - Jon On Jan 27, 2011, at 10:06 AM, Burkhard Linke wrote: > Hi, > > signal handlers registered with signal(3) behave in a somewhat different way > for Sys V systems, e.g. Solaris. The manpage states that during the execution > of the signal handler, the signal disposition is set to SIG_DFL. This raises > two problems: > > a) a possible race condition, if the same signal occurs during the execution > of its signal handler > > b) handling the signal a second time, since the manpage (and the > implementation under Solaris..) does not reinstall the signal handler. > > The attached test program uses Mono.Unix.Signal to catch signals. Executing > it > under Solaris/x86 running Mono 2.8.1, Mono 2.6.7 and the git master gives the > following output: > > running as process 29499 > sending first HUP > sending second HUP > Hangup > > The second SIGHUP is not catched by the signal handler, terminating the > application (which is the default for SIGHUP). > > The applied patch solves the problem by replacing signal(3) with sigset(3). > sigset's semantic differs from signal's one; Instead of setting the signal to > default handling, it adds the signal to the process/threads signal masks, > executed the signal handler and restores the signal mask. Both problems > mentioned above are solved. Test program output after applying the patch to > git master: > > running as process 172 > sending first HUP > sending second HUP > sending third HUP > terminating > > > With best regards, > Burkhard Linke > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Exception in runtime-invoke Wrapper
Hello Robert, thank you for your answer! On 24.01.2011 18:08, Robert Jordan wrote: > You may want to look at how Mono is handling those > wrappers with its full-AOT subsystem. Actually, my pre-compilation code bases on the Full-AOT code of Mono 2.6.1. Particularly, it uses code of 'collect_methods()' and 'add_wrappers()'. Instead of calling 'add_method()' in order to add a chosen method to the AOT-compile structure, my pre-compilation code calls 'mono_compile_method()' in order to pre-compile the method. Quite simple. However, the signature sharing seems to work not properly for my purposes. In 'mono_marshal_get_runtime_invoke()' the 'runtime_invoke_cache' returns one wrapper for different call signature, e.g., for 'System.Threading.WaitHandle:set_Handle()' and 'System.Attribute:System.Runtime.InteropServices._Attribute.GetTypeInfoCount()'. As far as I see, the code of 'add_wrappers()' and 'mono_marshal_get_runtime_invoke() 'is nearly the same in Mono 2.8.2 (which supports Full-AOT for x86) and it seems to work there. Does the signature comparison function have changed since Mono 2.6.1? With kind regards, Martin Däumler ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Incorrect signal handling for Sys V signal handler
Hi,
signal handlers registered with signal(3) behave in a somewhat different way
for Sys V systems, e.g. Solaris. The manpage states that during the execution
of the signal handler, the signal disposition is set to SIG_DFL. This raises
two problems:
a) a possible race condition, if the same signal occurs during the execution
of its signal handler
b) handling the signal a second time, since the manpage (and the
implementation under Solaris..) does not reinstall the signal handler.
The attached test program uses Mono.Unix.Signal to catch signals. Executing it
under Solaris/x86 running Mono 2.8.1, Mono 2.6.7 and the git master gives the
following output:
running as process 29499
sending first HUP
sending second HUP
Hangup
The second SIGHUP is not catched by the signal handler, terminating the
application (which is the default for SIGHUP).
The applied patch solves the problem by replacing signal(3) with sigset(3).
sigset's semantic differs from signal's one; Instead of setting the signal to
default handling, it adds the signal to the process/threads signal masks,
executed the signal handler and restores the signal mask. Both problems
mentioned above are solved. Test program output after applying the patch to
git master:
running as process 172
sending first HUP
sending second HUP
sending third HUP
terminating
With best regards,
Burkhard Linke
diff --git a/mono/io-layer/daemon-messages.c b/mono/io-layer/daemon-messages.c
index 812d435..0c8ce44 100644
--- a/mono/io-layer/daemon-messages.c
+++ b/mono/io-layer/daemon-messages.c
@@ -85,7 +85,7 @@ static void _wapi_daemon_request_response_internal (int fd,
}
while (ret==-1 && errno==EINTR);
#else
- old_sigpipe = signal (SIGPIPE, SIG_IGN);
+ old_sigpipe = sigset (SIGPIPE, SIG_IGN);
do {
ret=sendmsg (fd, msg, 0);
}
@@ -113,7 +113,7 @@ static void _wapi_daemon_request_response_internal (int fd,
ret=recv (fd, resp, sizeof(WapiHandleResponse), 0);
}
while (ret==-1 && errno==EINTR);
- signal (SIGPIPE, old_sigpipe);
+ sigset (SIGPIPE, old_sigpipe);
#endif
if(ret==-1) {
diff --git a/mono/metadata/threadpool.c b/mono/metadata/threadpool.c
index 105ecf3..f1056fe 100644
--- a/mono/metadata/threadpool.c
+++ b/mono/metadata/threadpool.c
@@ -1352,7 +1352,7 @@ mono_thread_pool_init ()
g_assert (async_io_tp.pc_nthreads);
tp_inited = 2;
#ifdef DEBUG
- signal (SIGALRM, signal_handler);
+ sigset (SIGALRM, signal_handler);
alarm (2);
#endif
}
diff --git a/support/signal.c b/support/signal.c
index abd7638..32450d8 100644
--- a/support/signal.c
+++ b/support/signal.c
@@ -217,7 +217,7 @@ Mono_Unix_UnixSignal_install (int sig)
for (i = 0; i < NUM_SIGNALS; ++i) {
if (h == NULL && signals [i].signum == 0) {
h = &signals [i];
- h->handler = signal (sig, default_handler);
+ h->handler = sigset (sig, default_handler);
if (h->handler == SIG_ERR) {
h->handler = NULL;
h = NULL;
@@ -280,7 +280,7 @@ Mono_Unix_UnixSignal_uninstall (void* info)
else {
/* last UnixSignal -- we can unregister */
if (h->have_handler && count_handlers (h->signum) == 1) {
- mph_sighandler_t p = signal (h->signum, h->handler);
+ mph_sighandler_t p = sigset (h->signum, h->handler);
if (p != SIG_ERR)
r = 0;
h->handler = NULL;
using System;
using System.Threading;
using Mono.Unix;
using Mono.Unix.Native;
namespace SignalTest
{
class MainClass
{
public static void Main (string[] args)
{
// get our PID
int pid = Mono.Unix.UnixProcess.GetCurrentProcessId ();
System.Console.Error.WriteLine ("running as process {0}", pid);
// install signal handler for SIGUP
UnixSignal sighup = new UnixSignal (Signum.SIGHUP);
// handle signals in a thread
new Thread (delegate() {
while (true) {
sighup.WaitOne ();
System.Console.Error.WriteLine ("got HUP signals");
}
}).Start ();
System.Console.Error.WriteLine ("sending first HUP");
Mono.Unix.UnixProcess.GetCurrentProcess ().Signal (Signum.SIGHUP);
System.Console.Error.WriteLine ("sending second HUP");
Mono.Unix.UnixProcess.GetCurrentProcess ().Signal (Signum.SIGHUP);
System.Console.Error.WriteLine ("sending third HUP");
Mono.Unix.UnixProcess.GetCurrentProcess ().Signal (Signum.SIGHUP);
System.Console.Error.WriteLine ("terminating");
System.Environment.Exit (0);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Support for newer Boehm-GC versiobs (7.2 + cvs)
Applied it to HEAD/2.10. Zoltan On Thu, Jan 27, 2011 at 3:22 PM, Burkhard Linke < bli...@cebitec.uni-bielefeld.de> wrote: > Hi, > > the applied patch vs. the mono git master adds support for newer versions > of > the Boehm GC, including CVS snapshots. > > An updated version of Boehm GC is necessary to compile Mono for Solaris/x86 > and Solaris/SPARC. > > With best regard, > Burkhard Linke > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Support for newer Boehm-GC versiobs (7.2 + cvs)
Hi,
the applied patch vs. the mono git master adds support for newer versions of
the Boehm GC, including CVS snapshots.
An updated version of Boehm GC is necessary to compile Mono for Solaris/x86
and Solaris/SPARC.
With best regard,
Burkhard Linke
diff --git a/configure.in b/configure.in
index 8ab977a..5cd56ae 100644
--- a/configure.in
+++ b/configure.in
@@ -851,6 +851,14 @@ case "x$gc" in
if test "x$found_gc_enable" = "xyes"; then
BOEHM_DEFINES="-DHAVE_GC_ENABLE $BOEHM_DEFINES"
fi
+
+ # check whether we need to explicitly allow
+ # thread registering
+ AC_CHECK_LIB(gc, GC_allow_register_threads, found_allow_register_threads="yes",,$libdl)
+ if test "x$found_allow_register_threads" = "xyes"; then
+AC_DEFINE(HAVE_GC_ALLOW_REGISTER_THREADS, 1, [GC requires thread registration])
+ fi
+
;;
xincluded)
diff --git a/mono/metadata/boehm-gc.c b/mono/metadata/boehm-gc.c
index ac327c5..5484e68 100644
--- a/mono/metadata/boehm-gc.c
+++ b/mono/metadata/boehm-gc.c
@@ -132,6 +132,10 @@ mono_gc_base_init (void)
GC_init_gcj_malloc (5, NULL);
#endif
+#ifdef HAVE_GC_ALLOW_REGISTER_THREADS
+ GC_allow_register_threads();
+#endif
+
if ((env = getenv ("MONO_GC_PARAMS"))) {
char **ptr, **opts = g_strsplit (env, ",", -1);
for (ptr = opts; *ptr; ++ptr) {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoTools -- remote test runner?
You can use PNunit, that runs tests remotely, over many machines in parallel if needed. AFAIR, PNUnit is distributed with recent versions of NUnit, and works in .NET and Mono, over lots of operating systems. Google a bit, have fun, Rafael "Monoman" Teixeira --- "We live in a world operated by science and technology. We have also arranged things so that almost no one understands science and technology. This is a prescription for disaster. We might get away with it for a while, but sooner or later this combustible mixture of ignorance and power is going to blow up in our faces." -Carl Sagan On Thu, Jan 27, 2011 at 3:13 AM, Sebastian Good wrote: > Is it possible using MonoTools -- or to extend MonoTools -- to run unit > tests remotely? It would be very convenient to be able to kick off one or > more NUnit tests on a mono target. > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono wiki about debugging
Added it. Zoltan On Thu, Jan 27, 2011 at 1:19 PM, Alexander Stohr wrote: > hello, > > this page is probably missing several very useful hints: > http://www.mono-project.com/Debugging > > i think a hint for the environment variable option "MONO_LOG_LEVEL=debug" > is pretty recommended as this is often already very helpful in showing why > Mono does not behave as expected. good tracing facilities are built into > mono (printf is a debugger that almost always should work even if nothing > else will work) and they will work instantly without too much fuzz. > > you probably know much more choices than i. > the info about their existence should be included in such a central page. > > regards Alex. > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono wiki about debugging
hello, this page is probably missing several very useful hints: http://www.mono-project.com/Debugging i think a hint for the environment variable option "MONO_LOG_LEVEL=debug" is pretty recommended as this is often already very helpful in showing why Mono does not behave as expected. good tracing facilities are built into mono (printf is a debugger that almost always should work even if nothing else will work) and they will work instantly without too much fuzz. you probably know much more choices than i. the info about their existence should be included in such a central page. regards Alex. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
