[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
Re: [Mono-dev] mono wiki about debugging
Added it. Zoltan On Thu, Jan 27, 2011 at 1:19 PM, Alexander Stohr alexander.st...@gmx.dewrote: 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
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 sebast...@palladiumconsulting.com 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
[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] [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] 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] 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
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_sigset.diffMain.cs___ 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
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 jonpr...@vt.edu 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_sigset.diffMain.cs___ 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] 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
[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-list] System.Net.NetworkInformation: network availability
Thank you for your kind reply. Anyway yes, I'm sure those are the functions of framework .Net 2.0 I need. They serve me well on the Microsoft counterpart. I expressly need to avoid pinging or querying some specific servers. I temporarily resolved using NDesk.Dbus libraries, until someone will put his hands on that part of framework. I do hope that code will be implemented, cause it's annoying and could be hard to maintain two sections of our application that do the same things. Mat. -- View this message in context: http://mono.1490590.n4.nabble.com/System-Net-NetworkInformation-network-availability-tp3206752p3241649.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
Chances are you're going to be told you're running an old Mono version and
should try with a more recent one.
Can you upgrade?
batuakan wrote:
Hello,
I have been trying to write a simple c# program to dynamically load a
shared object file under mono 2.4.4, in linux environment. My call to
dlload function ends up a SIGSEGV and the application exits I tried with
several shared objects, the system seems to be able find them, but still
unable to load. What might be the problem?
Thanks
Batu
c# source code
-
using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
namespace swi
{
class MainClass
{
[DllImport(libdl.so, CallingConvention =
CallingConvention.Cdecl,
CharSet = CharSet.Auto)]
private static extern IntPtr dlopen([In] string filename, [In]
int
flags);
public static void Main (string[] args)
{
IntPtr handle = dlopen(libc.so.6, 0x02);
if (handle == null)
Console.WriteLine(Unable to load shared
object);
else
Console.WriteLine(Shared object successfully
loaded);
}
}
}
Application Output
-
Module loaded: swi, Version=1.0.4044.28138, Culture=neutral,
PublicKeyToken=null.
Stacktrace:
at (wrapper managed-to-native) swi.MainClass.dlopen (string,int)
0x4
at (wrapper managed-to-native) swi.MainClass.dlopen (string,int)
0x
at swi.MainClass.Main (string[]) [0x0] in
/home/batuakan/Projects/swi/Main.cs:16
at (wrapper runtime-invoke) swi.MainClass.runtime_invoke_void_object
(object,intptr,intptr,intptr) 0x
Native stacktrace:
/usr/bin/mono() [0x80ca6e4]
/usr/bin/mono() [0x80f6893]
[0xb77cd410]
/lib/ld-linux.so.2(+0x11688) [0xb77df688]
/usr/lib/libdl.so(+0xc0b) [0xb6ff0c0b]
/lib/ld-linux.so.2(+0xd7e6) [0xb77db7e6]
/usr/lib/libdl.so(+0x109c) [0xb6ff109c]
/usr/lib/libdl.so(dlopen+0x41) [0xb6ff0b41]
[0xb6ff53a9]
[0xb6ff52f9]
[0xb6ff525b]
/usr/bin/mono(mono_runtime_exec_main+0xde) [0x8113b1e]
/usr/bin/mono(mono_runtime_run_main+0x15a) [0x811429a]
/usr/bin/mono(mono_debugger_main+0x77) [0x80f9e67]
/usr/bin/mono(mono_main+0x150c) [0x80b316c]
/usr/bin/mono() [0x805ad25]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb7551bd6]
/usr/bin/mono() [0x805ac61]
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=
Thread 2 exited.
Thread 3 exited.
Thread 1 exited.
Process 1 exited.
Target exited.
--
View this message in context:
http://mono.1490590.n4.nabble.com/dlopen-problem-on-Mono-2-4-4-tp3241535p3241838.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
Hello, I upgraded to mono version 2.6.7 but I still have the same problem. So of the hex numbers has changed but I still get the same output. Does it work on your system? b. -- View this message in context: http://mono.1490590.n4.nabble.com/dlopen-problem-on-Mono-2-4-4-tp3241535p3242139.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
On 27.01.2011 13:57, batuakan wrote: Hello, I upgraded to mono version 2.6.7 but I still have the same problem. So of the hex numbers has changed but I still get the same output. Does it work on your system? What Linux system are you on? I cannot reproduce it with Mono 2.4, 2.6, 2.8, 2.10. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] System.Net.NetworkInformation: network availability
Hello Mattia, I temporarily resolved using NDesk.Dbus libraries, until someone will put his hands on that part of framework. I do hope that code will be implemented, cause it's annoying and could be hard to maintain two sections of our application that do the same things. We currently do not have plans to implement that part of the stack for Linux. So having two code paths is the best possible option at this point in time. If someone wanted to contribute the code, they would have to use DBus, just like you did, to detect this sort of condition. Now, we can not take a depedency on DBusSharp directly, so this would have to be some sort of dynamically loaded code that invokes the proper methods. Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Messages in apache error log
Hi folks, I'm using mono (with sgen), xsp and mod_mono from master (master/7f146f9 Tue Jan 18 21:07:17) on Ubuntu Server 11.04 with apache 2.2.16. I'm hosting there several ASP.NET MVC 2 web applications either on mod-mono-server2 or mod-mono-server4 and I can see in error.log of apache these kind of error messages: [Thu Jan 27 15:59:26 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:26 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:27 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:27 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) [Thu Jan 27 15:59:28 2011] [error] command failed: failed to send file (file data) and sometimes these exceptions: (info) Auto generated encryption keys not saved: System.Security.SecurityException: No access to the given key at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir, Boolean is_volatile) [0x0] in filename unknown:0 at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir) [0x0] in filename unknown:0 at Microsoft.Win32.KeyHandler.Lookup (Microsoft.Win32.RegistryKey rkey, Boolean createNonExisting) [0x0] in filename unknown:0 at Microsoft.Win32.UnixRegistryApi.OpenSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x0] in filename unknown:0 at Microsoft.Win32.RegistryKey.OpenSubKey (System.String name, Boolean writable) [0x0] in filename unknown:0 at (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey:OpenSubKey (string,bool) at System.Web.Configuration.MachineKeyRegistryStorage.OpenRegistryKey (System.String path, Boolean write) [0x0] in filename unknown:0 at System.Web.Configuration.MachineKeyRegistryStorage.Store (System.Byte[] buf, KeyType kt) [0x0] in filename unknown:0 Websites are working correctly (at least I didn't notice any unwanted behavior during testing), but I'm little bit concerned about these messages in error log. Any ideas where might be the problem? Thanks for your time and help. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] SslStream error
When http://www.mail-archive.com/mono-bugs@lists.ximian.com/msg74245.html error in Mono will be solved?? -- View this message in context: http://mono.1490590.n4.nabble.com/SslStream-error-tp3242597p3242597.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
No idea about the SIGSEGV, but your code could use some improvement...
On Jan 27, 2011, at 1:43 AM, batuakan wrote:
c# source code
-
using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
namespace swi
{
class MainClass
{
[DllImport(libdl.so, CallingConvention =
CallingConvention.Cdecl,
CharSet = CharSet.Auto)]
First of all, libdl.so may not exist; it certainly doesn't exist on my
openSUSE 11.2 installation, as it's part of a debug package which I don't have
installed. You either want to [DllImport (libdl.so.2)] or provide a
.exe.config file which maps libdl.so to the actual library:
http://www.mono-project.com/Config_DllMap
private static extern IntPtr dlopen([In] string filename, [In]
int flags);
[In] isn't necessary (as it's the default), but it won't hurt anything either.
public static void Main (string[] args)
{
IntPtr handle = dlopen(libc.so.6, 0x02);
if (handle == null)
This is wrong; it will ~never be true, as in order to operate you would need to
box the IntPtr into an object to compare against null, and a boxed object will
obviously never be null.
(Plus, iirc many mcs versions will error on the above code because the C# spec
was interpreted to prevent that, as it's obviously non-sensical.)
Instead, you should do:
if (handle == IntPtr.Zero)
- Jon
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mmap(...PROT_NONE...) failed
On Mon, 2011-01-24 at 16:37 +0300, Yury Serdyuk wrote: Hi ! I have some multithreaded program in which the threads are created and destroyed dynamically. I run my program on multi-core machine and it constantly failed with mmap(...PROT_NONE...) failed [...] You're running out of memory. -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
Hmm that sounds rather strange that, you were able to run the code without any segfaults. I am using ubuntu 10.04 with kernel version 2.6.32-27-generic-pae Batu -- View this message in context: http://mono.1490590.n4.nabble.com/dlopen-problem-on-Mono-2-4-4-tp3241535p3243551.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] dlopen problem on Mono 2.4.4
Hello all, A system wide upgrade solved the problem automagically. I should pay more attentions to such details. Thank you all for your help. @Jonathan I am aware that it is bad code. I just wanted to present the forum a simple code. I want to port a library developed for windows to work under Linux. And at one part in the library it loads a shared object to access to an callback function pointer and change it to a local function pointer. -- View this message in context: http://mono.1490590.n4.nabble.com/dlopen-problem-on-Mono-2-4-4-tp3241535p3243561.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] CSharp interpreter feedback, and a gift
Mono devs, I've just been working the CSharp interpreter and have some suggestions for easier use: 1) a single evaluate function which could handle expressions and statements. 2) able to evaluate multiple statements, without evaluating them one by one. 3) handle errors through a return or raised exception, rather than through a side-effect print to Console.Out, or Console.Error I haven't looked into how the Csharp interpreter actually works, but it would be excellent if the user could define functions and classes, in the environment. Would that be possible? And a gift: wouldn't be handy to use the CSharp interpreter side-by-side with Python, Ruby, Boo, Lisp, and Scheme, all in an interpreted shell-editor, even sharing data and code? Now you can. I've just added CSharp interpreter to the Pyjama Project, http://PyjamaProject.org It would be great to be able to have C# as one of the languages to use in this educational environment, but until it can address functions and classes, it will be a second-class citizen. Although, it will be a nice step for students to be able to take to see a fully-typed, explicit language---even as it is interpreted. If any one has suggestions about using C# in the educational environment, please let me know. -Doug ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] CSharp interpreter feedback, and a gift
1) a single evaluate function which could handle expressions and statements. This is already the case. 2) able to evaluate multiple statements, without evaluating them one by one. That is also the case. 3) handle errors through a return or raised exception, rather than through a side-effect print to Console.Out, or Console.Error I have to look into this one in particular, are these compilation errors, or the execution errors? You can control where the error messages go by assigning a TextWriter object to the InteractiveBase class's Output and Error properties. I haven't looked into how the Csharp interpreter actually works, but it would be excellent if the user could define functions and classes, in the environment. Would that be possible? It is not currently possible. This requires some work on the compiler to enable the feature. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] CSharp interpreter feedback, and a gift
On Jan 27, 2011, at 9:52:35PM, Doug Blank wrote:
It would be great to be able to have C# as one of the languages to use
in this educational environment, but until it can address functions
and classes, it will be a second-class citizen. Although, it will be a
nice step for students to be able to take to see a fully-typed,
explicit language---even as it is interpreted.
If any one has suggestions about using C# in the educational
environment, please let me know.
-Doug
If you're willing to fake it, you can define functions as lambdas. It'll be ~=
to defining them in a real sense.
Try something like this:
ActionT printMe = t = Console.WriteLine (t);
or in the more complex case (retrieving some content from a webserver that
always returns GZip [yes, I did run into this while exploring some services via
the REPL]):
Funcstring, string doRequestWithPayload = payload = {
var wc = new WebClient ();
var data = wc.UploadData (http://url:port/service;, POST,
Encoding.UTF8.GetBytes (payload));
return new StreamReader (new GZipStream (new MemoryStream
(data), CompressionMode.Decompress)).ReadToEnd ();
}
It works perfectly well in the interpreter. It's not quite a real function
definition, but it's close enough for most purposes. Classes on the other hand
are a no-go.
—Bojan
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
