Re: [Mono-dev] [PATCH] Enable sgen on sparc and Solaris
On 01/10/2010 2:35PM, Dick Porter wrote: Hi all Attached is a patch that implements the arch-specific register handling code for sparc, and ports the x86 ucontext macros to OpenSolaris/x86 (also enabling sgen for this platform). Ok to commit these patches to git head? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Finalizers in CriticalHandle
On Sat, 2011-01-22 at 00:09 -0500, Gonzalo Paniagua Javier wrote: I think a more correct patch would be the one attached. Avoids having 'if (Invalid) return;' followed by 'if (!Invalid)...'. Sure. I just wanted to highlight the obviousness of the change. I'll commit your version. Miguel has asked me to commit it to 2-10 and master. Should I add it to 2-8 as well? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Finalizers in CriticalHandle
On Mon, 2011-01-24 at 11:22 +0100, Robert Jordan wrote: On 24.01.2011 11:11, Dick Porter wrote: Sure. I just wanted to highlight the obviousness of the change. I'll commit your version. Gonzalo has already committed this to master (a9d2a487) 2-10 (234a2d72). Oops, missed that. Saves me a task then :) - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Finalizers in CriticalHandle
On 17 Jan 2011, at 6:00PM, Rodrigo Kumpera wrote: I'm not sure what the defined behavior is on this case, MSDN is not always accurate and we need to be as compatible with MS as possible. Could you please write a test case, and if the behavior you suggest is correct, send a patch which includes both the fix and the test case so we can move forward? Please see attached test case and diff. Test case on windows: C:\Documents and Settings\Administrator\Desktop\CriticalHandle \CriticalHandle\bin\DebugCriticalHandle.exe Handle 8 was released! Handle 3 was released! Handle 2 was released! Handle 1 was released! Handle 0 was released! Handle 7 was released! Handle 6 was released! Handle 5 was released! Handle 4 was released! Handle 9 was released! C:\Documents and Settings\Administrator\Desktop\CriticalHandle \CriticalHandle\bin\Debug Test case on unpatched mono, git master as of this afternoon: [dick@hagbard /tmp] [ 3:53PM] Mono HEAD :; mono CriticalHandleTest.exe [dick@hagbard /tmp] [ 3:53PM] Mono HEAD :; mono-sgen CriticalHandleTest.exe [dick@hagbard /tmp] [ 3:54PM] Mono HEAD :; Test case on patched mono: [dick@hagbard /tmp] [ 4:00PM] Mono HEAD :; mono CriticalHandleTest.exe Handle 7 was released! Handle 1 was released! Handle 6 was released! Handle 0 was released! Handle 5 was released! Handle 4 was released! Handle 3 was released! Handle 2 was released! Handle 8 was released! Handle 9 was released! [dick@hagbard /tmp] [ 4:00PM] Mono HEAD :; mono-sgen CriticalHandleTest.exe Handle 8 was released! Handle 7 was released! Handle 5 was released! Handle 6 was released! Handle 3 was released! Handle 4 was released! Handle 2 was released! Handle 0 was released! Handle 1 was released! Handle 9 was released! [dick@hagbard /tmp] [ 4:00PM] Mono HEAD :; - Dick CriticalHandleTest.cs Description: Binary data criticalhandle.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Finalizers in CriticalHandle
On Fri, 2011-01-14 at 17:26 +0100, Rodrigo Kumpera wrote: I suppose it is. Does .NET call Release on finalizer? I've no idea, but is there any reason why it shouldn't? It is after all supposed to be there for cleaning up unmanaged resources. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Finalizers in CriticalHandle
Hi all
I'm currently debugging an issue that appears to be caused by the
non-release of unmanaged resources in CriticalHandle. I'm using the git
master branch.
In CriticalHandle.cs:
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
~CriticalHandle ()
{
Dispose (false);
}
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
protected virtual void Dispose (bool disposing)
{
if (_disposed)
return;
_disposed = true;
if (IsInvalid)
return;
if (disposing == true !IsInvalid){
if (!ReleaseHandle ()) {
GC.SuppressFinalize (this);
} else {
// Failed in release...
}
}
}
Unless I'm missing something, this looks to me that when the
CriticalHandle object is finalized, the unmanaged resources won't be
released: ReleaseHandle() isn't called.
Is this a bug?
- Dick
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libgdiplus linecap issue
On Mon, 2010-10-04 at 18:43 -0700, Francis A. Bausch wrote: unfortunately i was not carefui enough in my analysis. this is my crash: [Error, 10/4/2010, 9:21:22 PM] UNHANDLED EXCEPTION: System.ArgumentException: A null reference or invalid value was found [GDI+ stat us: InvalidParameter] if otherend_x = x, or otherend_y=y, the calculation of slope may result in division by zero. I've committed a fix for this. Please check that it fixes the issue for you, as the previous code didn't crash for me even with the divide-by-zero. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fwd: register content changed
Hi all We're getting this assertion occasionally on Solaris. I don't have a particular test case, but does anyone know what it means? - Dick Begin forwarded message: From: psant...@codicesoftware.com psant...@codicesoftware.com Date: 10 October 2010 10:53:13 AMBST To: Dick Porter dpor...@codicesoftware.com Subject: register content changed got this running on Solaris. It happened to me several times in the past, randomly, both in SPARC and x86 0: 0 - 0 1: 92 - 0 2: 0 - 0 3: 0 - 0 4: - 0 5: fd3d1af4 - 0 6: 0 - 0 7: fe7f3400 - 0 8: 0 - 0 9: 1201c90 - 0 10: 0 - 0 11: 0 - 0 12: 0 - 0 13: 0 - 0 14: fc623d68 - 0 15: fed94070 - 0 16: 1 - 0 17: 0 - 0 18: 0 - 0 19: 0 - 0 20: 0 - 0 21: 0 - 0 22: 0 - 0 23: 0 - 0 24: fe7f3400 - 0 25: 0 - 0 26: 0 - 0 27: ff01 - 0 28: feeb60f0 - 0 29: 1 - 0 30: fc623dc8 - 0 31: fed95cd8 - 0 32: fe401003 - 0 33: fed9c580 - 0 34: fed9c584 - 0 35: 0 - 0 36: 0 - 0 37: 0 - 0 Register contents changed Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.Reflection.Emit.ILGenerator..ctor (System.Reflection.Module,System.Reflection.Emit.TokenGenerator,int) 0x00020 at System.Reflection.Emit.ConstructorBuilder.GetILGenerator (int) 0x000c0 at System.Reflection.Emit.ConstructorBuilder.GetILGenerator () 0xc at System .Runtime .Serialization .Formatters.Binary.CodeGenerator.GenerateMetadataTypeInternal (System.Type,System.Runtime.Serialization.StreamingContext) 0x001b8 at System .Runtime .Serialization.Formatters.Binary.CodeGenerator.GenerateMetadataType (System.Type,System.Runtime.Serialization.StreamingContext) 0x00048 at System .Runtime .Serialization.Formatters.Binary.ObjectWriter.CreateMemberTypeMetadata (System.Type) 0x00048 at System .Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectData (object ,System.Runtime.Serialization.Formatters.Binary.TypeMetadata,object) 0x005d4 at System .Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter,long,object) 0x0001c at System .Runtime .Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance (System.IO.BinaryWriter,object,bool) 0x001fc at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteValue (System.IO.BinaryWriter,System.Type,object) 0x00118 at PNUnitTestResult__TypeMetadata.WriteObjectData (System .Runtime .Serialization .Formatters.Binary.ObjectWriter,System.IO.BinaryWriter,object) 0x000a4 at System .Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter,long,object) 0x00338 at System .Runtime .Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance (System.IO.BinaryWriter,object,bool) 0x001fc at System .Runtime .Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects (System.IO.BinaryWriter) 0x00034 at System .Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph (System .IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Header[]) 0x00050 at System .Runtime .Serialization.Formatters.Binary.MessageFormatter.WriteMethodCall (System .IO .BinaryWriter ,object ,System .Runtime .Remoting .Messaging .Header [],System.Runtime.Serialization.Formatters.Binary.BinaryFormatter) 0x006b4 at System .Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) 0x0014c at System .Runtime .Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x001fc at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (System.Runtime.Remoting.Messaging.IMessage) 0x00478 at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System .Runtime .Remoting .Proxies .RealProxy ,System .Runtime.Remoting.Messaging.IMessage,System.Exception,object[]) 0x00430 at (wrapper runtime-invoke) Module.runtime_invoke_object_object_object_Exception_object[] (object,intptr,intptr,intptr) 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) 0x4 at (wrapper managed-to-native) object.__icall_wrapper_mono_remoting_wrapper (intptr,intptr) 0x at (wrapper remoting-invoke) PNUnit.Launcher.Runner.NotifyResult (string,NUnit.Core.TestResult) 0x at PNUnit.Agent.PNUnitTestRunner.ThreadProc () 0x00428 at (wrapper delegate-invoke) Module.invoke_void__this__ () 0x at System.Threading.Thread.StartUnsafe () 0x0008c at (wrapper delegate-invoke) Module.invoke_void__this__ () 0x at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 0x Abort (core dumped
[Mono-dev] [PATCH] Enable sgen on sparc and Solaris
Hi all
Attached is a patch that implements the arch-specific register handling
code for sparc, and ports the x86 ucontext macros to OpenSolaris/x86
(also enabling sgen for this platform).
I've also commented out the mono_jit_stats.method_trampolines increment
in tramp-sparc.c as that field doesn't exist in the stats struct.
The patch has been tested on Solaris/sparc. The sparcv9 part is
completely untested (we don't have a v9 machine). The x86 section has
been minimally tested on OpenSolaris.
- Dick
diff --git a/configure.in b/configure.in
index efe523a..b80ae22 100644
--- a/configure.in
+++ b/configure.in
@@ -2127,6 +2127,7 @@ case $host in
# foo.c:6: warning: visibility attribute not supported in this configuration; ignored
# ld: fatal: relocation error: R_386_GOTOFF: file /var/tmp//ccxYR96k.o: symbol astruct: relocation must bind locally
have_visibility_hidden=no
+ sgen_supported=true
;;
cygwin*)
have_visibility_hidden=no
@@ -2192,6 +2193,7 @@ case $host in
if test x$AR = xfalse; then
AC_MSG_ERROR([The required utility 'ar' is not found in your PATH. Usually it can be found in /usr/ccs/bin.])
fi
+ sgen_supported=true
;;
alpha*-*-linux* | alpha*-*-osf*)
TARGET=ALPHA;
diff --git a/mono/metadata/sgen-archdep.h b/mono/metadata/sgen-archdep.h
index 79514e9..a5ee335 100644
--- a/mono/metadata/sgen-archdep.h
+++ b/mono/metadata/sgen-archdep.h
@@ -208,6 +208,78 @@
((a)[15] = (gpointer) (UCONTEXT_GREGS((ctx))) [15]); \
} while (0)
+#elif defined(__sparc__)
+
+#define REDZONE_SIZE 0
+
+/* Don't bother with %g0 (%r0), it's always hard-coded to zero */
+#define ARCH_NUM_REGS 15
+#ifdef __sparcv9
+#define ARCH_STORE_REGS(ptr) \
+ __asm__ __volatile__( \
+ st %%g1,[%0]\n\t \
+ st %%g2,[%0+0x08]\n\t \
+ st %%g3,[%0+0x10]\n\t \
+ st %%g4,[%0+0x18]\n\t \
+ st %%g5,[%0+0x20]\n\t \
+ st %%g6,[%0+0x28]\n\t \
+ st %%g7,[%0+0x30]\n\t \
+ st %%o0,[%0+0x38]\n\t \
+ st %%o1,[%0+0x40]\n\t \
+ st %%o2,[%0+0x48]\n\t \
+ st %%o3,[%0+0x50]\n\t \
+ st %%o4,[%0+0x58]\n\t \
+ st %%o5,[%0+0x60]\n\t \
+ st %%o6,[%0+0x68]\n\t \
+ st %%o7,[%0+0x70]\n\t \
+ : \
+ : r (ptr) \
+ : memory \
+ )
+#else
+#define ARCH_STORE_REGS(ptr) \
+ __asm__ __volatile__( \
+ st %%g1,[%0]\n\t \
+ st %%g2,[%0+0x04]\n\t \
+ st %%g3,[%0+0x08]\n\t \
+ st %%g4,[%0+0x0c]\n\t \
+ st %%g5,[%0+0x10]\n\t \
+ st %%g6,[%0+0x14]\n\t \
+ st %%g7,[%0+0x18]\n\t \
+ st %%o0,[%0+0x1c]\n\t \
+ st %%o1,[%0+0x20]\n\t \
+ st %%o2,[%0+0x24]\n\t \
+ st %%o3,[%0+0x28]\n\t \
+ st %%o4,[%0+0x2c]\n\t \
+ st %%o5,[%0+0x30]\n\t \
+ st %%o6,[%0+0x34]\n\t \
+ st %%o7,[%0+0x38]\n\t \
+ : \
+ : r (ptr) \
+ : memory \
+ )
+#endif
+
+#define ARCH_SIGCTX_SP(ctx) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_SP])
+#define ARCH_SIGCTX_IP(ctx) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_PC])
+#define ARCH_COPY_SIGCTX_REGS(a,ctx) do { \
+ (a)[0] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G1]); \
+ (a)[1] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G2]); \
+ (a)[2] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G3]); \
+ (a)[3] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G4]); \
+ (a)[4] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G5]); \
+ (a)[5] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G6]); \
+ (a)[6] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_G7]); \
+ (a)[7] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O0]); \
+ (a)[8] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O1]); \
+ (a)[9] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O2]); \
+ (a)[10] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O3]); \
+ (a)[11] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O4]); \
+ (a)[12] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O5]); \
+ (a)[13] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O6]); \
+ (a)[14] = (gpointer) (((ucontext_t *)(ctx))-uc_mcontext.gregs [REG_O7]); \
+ } while (0)
+
#endif
#endif /* __MONO_SGENARCHDEP_H__ */
diff --git a/mono/mini/tramp-sparc.c b/mono/mini/tramp-sparc.c
index fa469c9..3bbe8bc 100644
--- a/mono/mini/tramp-sparc.c
+++ b/mono/mini/tramp-sparc.c
@@ -265,7 +265,7 @@ mono_arch_create_specific_trampoline (gpointer arg1, MonoTrampolineType tramp_ty
if (code_len)
*code_len = (code - buf) * 4;
- mono_jit_stats.method_trampolines++;
+ //mono_jit_stats.method_trampolines++;
mono_arch_flush_icache ((guint8*)buf, (code - buf) * 4);
diff --git a/mono/utils/mono-sigcontext.h b/mono/utils/mono-sigcontext.h
index a794a28..0cd3bc5 100644
--- a/mono/utils/mono-sigcontext.h
+++ b/mono/utils/mono-sigcontext.h
@@ -67,6 +67,16 @@
#define UCONTEXT_REG_ESI(ctx) (((ucontext_t*)(ctx))-sc_esi)
#define UCONTEXT_REG_EDI(ctx) (((ucontext_t*)(ctx))-sc_edi)
#define UCONTEXT_REG_EIP(ctx) (((ucontext_t*)(ctx))-sc_eip)
+#elif defined(PLATFORM_SOLARIS)
+ #define
Re: [Mono-dev] Stability regression on recent git head
On 15 Sep 2010, at 6:35PM, Jonathan Pryor wrote: I committed a workaround for this in commit 8cdb685. Could you see if that works for you? Hi Jon Unfortunately I still get the exact same crash with today's git head. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Stability regression on recent git head
On 16 Sep 2010, at 4:52PM, Miguel de Icaza wrote: Could you try master, I committed what I believe is the fix. If it works, we can put it on 2.8 It still crashes with the same stack trace, even with git master as of a couple of minutes ago. I double-checked, and your change is there. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Stability regression on recent git head
Hi all We've been testing the sgen GC with our server, as part of the effort to stabilise it. Recently however we've noticed that the runtime has been very unstable, in particular using the _Boehm_ GC. I can start our server with this morning's git head runtime, with Boehm GC, and as soon as I issue a client command (which uses remoting) I get the following stack trace on the server: Plastic SCM daemon up. 3.0.187.2 1151 ms startup time Stacktrace: at (wrapper managed-to-native) Mono.Unix.UnixSignal.WaitAny (intptr[],int,int) 0x3 at (wrapper managed-to-native) Mono.Unix.UnixSignal.WaitAny (intptr[],int,int) 0x3 at Mono.Unix.UnixSignal.WaitAny (Mono.Unix.UnixSignal[],int) 0x0011e at Mono.Unix.UnixSignal.WaitAny (Mono.Unix.UnixSignal[]) 0x00012 at Codice.CM.Daemon.Daemon.HandleSignals () 0x0013a at Codice.CM.Daemon.Daemon.LaunchUnixDaemon (Codice.CM.Server.ISystemRunner,string) 0x00036 at xy.c (Codice.CM.Server.SystemRunner) 0x0005f at xy.a (an) 0x0035c at xy.a (string[]) 0x000b1 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x0008f This is 100% repeatable, with the identical stack trace every time. Interestingly, it doesn't happen with the sgen GC though I have seen this stack trace appear intermittently with sgen, which suggests to me that there might be some memory corruption going on that is more likely to be tickled by the Boehm GC. The actual line of code that triggers the segfault is in mono/support/signal.c, in wait_for_any(): diff --git a/support/signal.c b/support/signal.c index abd7638..a7f97fa 100644 --- a/support/signal.c +++ b/support/signal.c @@ -351,7 +351,7 @@ wait_for_any (signal_info** signals, int count, int *currfd, ptv = tv; } r = poll (fd_structs, count, timeout); - } while (keep_trying (r) !shutting_down ()); + } while (keep_trying (r) /* !shutting_down ()*/); idx = -1; if (r == 0) Commenting out the delegate call cures the crash for me. I reopened bug https://bugzilla.novell.com/show_bug.cgi?id=592981 with these traces, but as no-one has commented on it in a couple of weeks I'm highlighting it here too. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.GetCurrentProcess().MainModule.FileName broken on 2.6.1 on FreeBSD
On Wed, 2010-02-10 at 18:10 -0200, Rodrigo Kumpera wrote: On Wed, Feb 10, 2010 at 6:05 PM, psant...@codicesoftware.com psant...@codicesoftware.com wrote: [tes...@freebox ~/test]$ ../mono/bin/mono main.exe Unhandled Exception: System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count. Parameter name: index 0 FreeBSD is not a supported OS, it basically works by virtue of been very similar to OSX. So, if you're lucky, and fails on OSX, just file a bug report and we'll work on it. Beyond that, all we can do is to gladly accept patches from the community. It turns out it is a FreeBSD configuration issue. By default, FreeBSD doesn't mount /proc. Do so, and the test works. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Preliminary ia64-hpux porting committed
Hi all I've committed the first bits of a port to ia64-hpux, in the branch /source/branches/dick/ia64-hpux The approach I took was to let the compiler work in the existing little-endian mode, and byteswap when the instructions are emitted. This kept code changes to a minimum. I'm not sure I completely figured out the patching code, so I'm not 100% certain that the byteswapping is happening in the right place, but a different attempt at byteswapping much later in the compilation process gave precisely the same results. Code generation seems to work: the disassembled code output when run with sufficient verbosity matches the ia64-linux output. However, executing the generated code segfaults straight away. I suspect this is coming from the unwinding code - it took me several goes to get libunwind built for hpux, and I'm still not convinced it's working correctly. Unfortunately we won't be able to spend any more time on this in the near future, so it's being committed into svn in the hope that others can take it up. Thanks are due to Miguel and Thomas for arranging access to an ia64-linux machine while I was working on this, which made the work a lot easier. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] IA-64 big-endian
Hi all I've been spending the last couple of days getting mono to build on ia-64/hpux - mostly so far setting up GNU tools from scratch. I've now run into a showstopper: mono/arch/ia64/ia64-codegen.h #if G_BYTE_ORDER != G_LITTLE_ENDIAN #error FIXME #endif So my question is, is fixing this going to be a case of a few fixes here and there (that I might be able to do without a hardware manual), or is it going to be a full-blown port? Thanks, - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with GC due to libgc
On Wed, 2009-09-30 at 10:24 +0200, David Suarez wrote: Hi Zoltan, Let me point some data from our tests to the discussion. Those blocks up to 100Mb are actually leaked I'm afraid. If you do again the same operation in the sample (allocate 2.5GB), your virt memory will again go up to 2.5GB + the free blocks, so they seem to be not so free. To follow up from David, the amount of 'leakage' is also variable from run to run. If it was just plain fragmentation I would expect the memory usage to be at least consistent. We are also seeing that some objects are being allocated without a GC descriptor. I noted Zoltan's response about the GC_GCJ_MALLOC functions and need to read the code again. We also have a theory that with libgc the false pointers on the stack aren't being removed from the mark stack when the execution stack unwinds. I will be investigating this. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with GC due to libgc
On Mon, 2009-09-28 at 17:41 -0400, Miguel de Icaza wrote: Hello, Libgc supports this kind of descriptors and mono already generates them for the sgen gc, so it's just a matter of joining those together (which should beeasy to do). This should improve a great number of scans in the arking process, leaving only stacks and several minor objects without precise marking. (Should become similar to the current sgen idea, where stacks and other roots are scanned conservatively, although not compacting). Mono already uses those descriptors for the heap; There are only two cases when it does not use that: * Scanning the stack, this is done with the conservative collector. * Any AppDomains that are not the root appdomain. I've been looking through the code in svn head. The only place I can see an object allocated with mono_gc_alloc_fixed () with the descr parameter not NULL (which is the only place in boehm-gc mode that calls GC_MALLOC_EXPLICITLY_TYPED ()) is in object.c, mono_class_create_runtime_vtable() when class-has_static_refs is true. Am I missing something here? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RFC: GC precise scanning of stacks
Hi all
We think some of our 'leak' issues can be attributed to libgc's
false-positive identification of pointers.
Attached is a proof-of-concept patch to libgc (and a simple
demonstration program) that I hope will be the start of GC precise stack
scanning. The code should apply easily to sgen as well.
It basically adds an extra variable to the stack which contains specific
markers and references to all the pointers that will contain GC-alloced
memory. There is an optional failsafe mode that will fall back to the
current 'all stack is scanned' code if the markers are not seen.
This code will cover objects on unmanaged stacks but I don't know what
will be needed for managed code. I presume the JIT can add the same
sort of marker to the stack?
So, comments? Is this technique going to be workable?
- Dick
diff -urBbw gc6.6-orig/include/gc.h gc6.6/include/gc.h
--- gc6.6-orig/include/gc.h 2005-05-20 18:50:58.0 +0100
+++ gc6.6/include/gc.h 2009-09-28 11:17:45.0 +0100
@@ -859,6 +859,20 @@
# define GC_PTR_STORE(p, q) *((p) = (q))
#endif
+#ifdef GC_PRECISE_STACK
+/* Keep the least significant bit set so these don't look like pointers */
+# define GC_PRECISE_STACK_BEGIN_MARKER 0xF00FF00F
+# define GC_PRECISE_STACK_END_MARKER 0xD00DD00D
+/* This macro is very gcc specific, with the 'unused' attribute to
+ * shut up the unused-variable warning, the volatile placement to foil the
+ * optimiser, and the '##vars' to suppress the leading comma when the args
+ * list is empty
+ */
+# define GC_STACK_REFERENCE(x, vars...) __attribute__((unused)) void * volatile __GC_stack_references_ ## x[] = {(void *)GC_PRECISE_STACK_BEGIN_MARKER, ##vars, (void *)GC_PRECISE_STACK_END_MARKER};
+#else
+# define GC_STACK_REFERENCE(x, vars...)
+#endif
+
/* Functions called to report pointer checking errors */
GC_API void (*GC_same_obj_print_proc) GC_PROTO((GC_PTR p, GC_PTR q));
diff -urBbw gc6.6-orig/pthread_stop_world.c gc6.6/pthread_stop_world.c
--- gc6.6-orig/pthread_stop_world.c 2005-09-09 18:54:32.0 +0100
+++ gc6.6/pthread_stop_world.c 2009-09-28 11:11:48.0 +0100
@@ -256,6 +256,10 @@
/* On IA64, we also need to scan the register backing store. */
IF_IA64(ptr_t bs_lo; ptr_t bs_hi;)
pthread_t me = pthread_self();
+#if GC_PRECISE_STACK
+ptr_t stack_ptr;
+int found_markers;
+#endif
if (!GC_thr_initialized) GC_thr_init();
#if DEBUG_THREADS
@@ -284,7 +288,7 @@
hi = GC_stackbottom;
IF_IA64(bs_lo = BACKING_STORE_BASE;)
}
-#if DEBUG_THREADS
+#if defined(DEBUG_THREADS) || defined(DEBUG_PRECISE_STACK)
GC_printf3(Stack for thread 0x%lx = [%lx,%lx)\n,
(unsigned long) p - id,
(unsigned long) lo, (unsigned long) hi);
@@ -292,10 +296,70 @@
if (0 == lo) ABORT(GC_push_all_stacks: sp not set!\n);
# ifdef STACK_GROWS_UP
/* We got them backwards! */
+# ifdef GC_PRECISE_STACK
+ found_markers = 0;
+
+ for (stack_ptr = hi; stack_ptr = lo; stack_ptr += sizeof(ptr_t)) {
+ word content = *(word *)stack_ptr;
+ if (content == GC_PRECISE_STACK_BEGIN_MARKER) {
+ ptr_t stack_ptr_end = stack_ptr;
+# ifdef DEBUG_PRECISE_STACK
+ GC_printf1(Found precise begin marker at 0x%lx\n, stack_ptr);
+# endif
+ found_markers = 1;
+ do {
+stack_ptr_end += sizeof(ptr_t);
+content = *(word *)stack_ptr_end;
+if (content != GC_PRECISE_STACK_END_MARKER) {
+ GC_push_all_stack ((ptr_t)content, (ptr_t)(content + sizeof(ptr_t)));
+}
+ } while (content != GC_PRECISE_STACK_END_MARKER
+stack_ptr_end lo);
+ stack_ptr = stack_ptr_end;
+ }
+ }
+
+# ifdef GC_PRECISE_STACK_FAILSAFE
+ if (!found_markers) {
+ GC_push_all_stack(hi, lo);
+ }
+# endif
+# else
GC_push_all_stack(hi, lo);
+# endif
+# else
+# ifdef GC_PRECISE_STACK
+ found_markers = 0;
+
+ for (stack_ptr = lo; stack_ptr = hi; stack_ptr += sizeof(ptr_t)) {
+ word content = *(word *)stack_ptr;
+ if (content == GC_PRECISE_STACK_BEGIN_MARKER) {
+ ptr_t stack_ptr_end = stack_ptr;
+# ifdef DEBUG_PRECISE_STACK
+ GC_printf1(Found precise begin marker at 0x%lx\n, stack_ptr);
+# endif
+ found_markers = 1;
+ do {
+stack_ptr_end += sizeof(ptr_t);
+content = *(word *)stack_ptr_end;
+if (content != GC_PRECISE_STACK_END_MARKER) {
+ GC_push_all_stack ((ptr_t)content, (ptr_t)(content + sizeof(ptr_t)));
+}
+ } while (content != GC_PRECISE_STACK_END_MARKER
+stack_ptr_end hi);
+ stack_ptr = stack_ptr_end;
+ }
+ }
+
+# ifdef GC_PRECISE_STACK_FAILSAFE
+ if (!found_markers) {
+ GC_push_all_stack(lo, hi);
+ }
+# endif
# else
GC_push_all_stack(lo, hi);
# endif
+# endif
# ifdef IA64
# if DEBUG_THREADS
GC_printf3(Reg stack for thread 0x%lx = [%lx,%lx)\n,
#define GC_PRECISE_STACK
#include gc.h
#include stdio.h
#include stdlib.h
typedef struct {
int val;
void *ptr;
} Object;
void
Re: [Mono-dev] Compacting GC
On Thu, 2009-09-10 at 19:09 +0200, Mark Probst wrote: On Thu, Sep 10, 2009 at 6:52 PM, pablosantosl...@terra.espablosantosl...@terra.es wrote: We tried to build it today since we're experiencing issues with libgc under really heavy load. SGen is not production-ready yet. It cannot even run the corlib testsuite completely, yet, so I doubt it will be of much use to you at this point. Hi Mark Is there a known list of jobs needed for sgen, or is it just a case of working through the failures and bugs? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
On 11 Sep 2009, at 3:26PM, Mark Probst wrote: On Fri, Sep 11, 2009 at 3:02 PM, Dick Porter dpor...@codicesoftware.com wrote: Is there a known list of jobs needed for sgen, or is it just a case of working through the failures and bugs? If you'd like to help, I'll write up a document with what I've learned debugging SGen. Yes please. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
Hi all Attached is a patch to add an optional asynchronous path for the TCP remoting channel server. The main benefit we see with this change is in reliability; when a single server is servicing many clients at once (we test with over 100) with large data transfers the standard synchronous channel will often drop connections. We tracked this down to the Accept() call in TcpServerChannel.cs not being able to get to incoming connections quickly enough. I was hoping that throughput of large transfers might be improved by using the threadpool's asynchronous sockets support, but it turns out that performance is pretty much the same as the current implementation. Any comments/suggestions for improvement? - Dick remoting.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Cause libgc to return some unused memory to the system
Hi all
Attached is a patch to libgc that will allow it to actually unmap memory
when USE_MUNMAP is defined. Currently, the unmap code just sets the
mmap flags on a region to 'no access'. The patch unlinks blocks from
the gc free list larger than a defined min size (currently 4k bytes),
that haven't been used for several collections, and unmaps the memory.
It may or may not fix https://bugzilla.novell.com/show_bug.cgi?id=495486
- the reporter forgot to attach his test case.
Comments?
- Dick
Index: include/private/gc_priv.h
===
--- include/private/gc_priv.h (revision 137556)
+++ include/private/gc_priv.h (working copy)
@@ -253,6 +253,8 @@
/* the block risks unreasonable immediate */
/* heap growth. */
+# define REALLY_FREE_MIN 4096
+
/*/
/* */
/* Stack saving for debugging */
@@ -908,6 +910,7 @@
# endif
# ifdef USE_MUNMAP
word _unmapped_bytes;
+word _really_unmapped_bytes;
# endif
# ifdef MERGE_SIZES
unsigned _size_map[WORDS_TO_BYTES(MAXOBJSZ+1)];
@@ -1054,6 +1057,7 @@
# define GC_last_stack GC_arrays._last_stack
# ifdef USE_MUNMAP
# define GC_unmapped_bytes GC_arrays._unmapped_bytes
+# define GC_really_unmapped_bytes GC_arrays._really_unmapped_bytes
# endif
# if defined(MSWIN32) || defined(MSWINCE)
# define GC_heap_bases GC_arrays._heap_bases
@@ -1780,6 +1784,7 @@
void GC_unmap(ptr_t start, word bytes);
void GC_remap(ptr_t start, word bytes);
void GC_unmap_gap(ptr_t start1, word bytes1, ptr_t start2, word bytes2);
+ void GC_really_unmap(ptr_t start, word bytes);
#endif
/* Virtual dirty bit implementation: */
Index: ChangeLog
===
--- ChangeLog (revision 137556)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2009-08-13 Dick Porter dpor...@codicesoftware.com
+
+ * include/private/gc_priv.h, allchblk.c, os_dep.c: Cause libgc to
+ return unused memory to the system in some cases.
+
2009-04-28 Zoltan Varga var...@gmail.com
* misc.c (GC_init): Avoid casting an lvalue. Fixes part of #498692.
Index: allchblk.c
===
--- allchblk.c (revision 137556)
+++ allchblk.c (working copy)
@@ -364,7 +364,7 @@
/* way blocks are ever unmapped. */
void GC_unmap_old(void)
{
-struct hblk * h;
+struct hblk * h, * next;
hdr * hhdr;
word sz;
unsigned short last_rec, threshold;
@@ -372,8 +372,9 @@
# define UNMAP_THRESHOLD 6
for (i = 0; i = N_HBLK_FLS; ++i) {
- for (h = GC_hblkfreelist[i]; 0 != h; h = hhdr - hb_next) {
+ for (h = GC_hblkfreelist[i]; 0 != h; h = next) {
hhdr = HDR(h);
+ next = hhdr - hb_next;
if (!IS_MAPPED(hhdr)) continue;
threshold = (unsigned short)(GC_gc_no - UNMAP_THRESHOLD);
last_rec = hhdr - hb_last_reclaimed;
@@ -382,6 +383,16 @@
sz = hhdr - hb_sz;
GC_unmap((ptr_t)h, sz);
hhdr - hb_flags |= WAS_UNMAPPED;
+
+#if !defined(MSWIN32) !defined(MSWINCE)
+ if (sz REALLY_FREE_MIN) {
+ GC_remove_from_fl(hhdr, i);
+ GC_remove_header(h);
+
+ /* Now really unmap the block */
+ GC_really_unmap ((ptr_t)h, sz);
+ }
+#endif
}
}
}
@@ -412,6 +423,7 @@
/* make both consistent, so that we can merge */
if (size nextsize) {
GC_remap((ptr_t)next, nextsize);
+ nexthdr - hb_flags = ~WAS_UNMAPPED;
} else {
GC_unmap((ptr_t)h, size);
hhdr - hb_flags |= WAS_UNMAPPED;
Index: os_dep.c
===
--- os_dep.c (revision 137556)
+++ os_dep.c (working copy)
@@ -1966,6 +1966,23 @@
# endif
}
+void GC_really_unmap(ptr_t start, word bytes)
+{
+ptr_t start_addr = GC_unmap_start(start, bytes);
+ptr_t end_addr = GC_unmap_end(start, bytes);
+word len = end_addr - start_addr;
+if (0 == start_addr) return;
+# if defined(MSWIN32) || defined(MSWINCE)
+ /* No idea what to do here */
+# else
+ {
+ int result;
+ result = munmap(start_addr, len);
+if (result != 0) ABORT(munmap() failed);
+ }
+ GC_really_unmapped_bytes += len;
+# endif
+}
#endif /* USE_MUNMAP */
/* Routine for pushing any additional roots. In THREADS */
signature.asc
Description: This is a digitally signed message part
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r123262 - trunk/mono/mono/io-layer
On Tue, 2009-01-13 at 16:43 -0500, Zoltan Varga (vargaz AT gmail.com)
wrote:
Author: zoltan
Date: 2009-01-13 16:43:23 -0500 (Tue, 13 Jan 2009)
New Revision: 123262
Reapply r122913, this time handling processes by falling back to
polling.
@@ -649,6 +650,11 @@
return(WAIT_FAILED);
}
+ for (i = 0; i numobjects; ++i)
+ if (_wapi_handle_type (handles [i]) == WAPI_HANDLE_PROCESS)
+ /* Can't wait for a process handle + another handle
without polling */
+ poll = TRUE;
+
done = test_and_own (numobjects, handles, waitall, count, lowest);
if (done == TRUE) {
return(WAIT_OBJECT_0+lowest);
This might handled more generally by using
_wapi_handle_test_capabilities (handles [i],
WAPI_HANDLE_CAP_SPECIAL_WAIT) == TRUE instead of checking specifically
for processes -- though iirc only processes currently have the 'special
wait' bit set.
- Dick
signature.asc
Description: This is a digitally signed message part
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement Process.WaitForInputIdle on Windows.
On Wed, 2008-11-12 at 17:35 -0500, Bill Holmes wrote: Hi, The attached patch is a better implementation of Process.WaitForInputIdle for Windows. The behavior for all other platforms has not changed. This looks fine to me for checking into trunk. I'm not sure who has the final say over the 2.2 branch at the moment. - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Wapi handle leaks problems
On Wed, 2008-02-20 at 09:51 +0100, Hubert FONGARNAND wrote: - don't you thing that a 4096 limit for WAPI handles is too small for big production servers? (on windows the number of handles is often 6000)? The shared memory part of io-layer is currently being rewritten to avoid the hard-coded limit (amongst other issues.) There is no timetable yet for its completion. - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] DriveInfo implementation - volume space
On Fri, 2007-12-07 at 14:45 +0100, Javier Martín wrote: Please don't introduce new files for only one function. Move it to io.c/io.h which already contains similar APIs. io.[hc] contains mainly file-like IO routines (files, pipes, console, etc.). This is about volume/mounts management. Adding a new file is OK, if we're likely to implement more functions for this type of thing. Furthermore, and even more important, I was planning to add at least two more functions in volumes.[hc] in other, unrelated patches to add the get/set volume label functionality and correct the bug I mentioned in the patch post (FS type not being detected in Windows). Note that io-layer is not used on Windows. More importantly, we will need a copyright assignment for a code contribution this big, or a declaration that you wrote the code and it is contributed under the X11 licence. From the FAQ (http://www.mono-project.com/FAQ:_Licensing): Why does Novell require a copyright assignment? When a developer contributes code to the C# compiler or the Mono runtime engine, we require that the author grants Novell the right to relicense his/her contribution under other licensing terms. This allows Novell to re-distribute the Mono source code to parties that might not want to use the GPL or LGPL versions of the code. Particularly embedded system vendors obtain grants to the Mono runtime engine and modify it for their own purposes without having to release those changes back. and the Porting guide (http://www.mono-project.com/Porting): Licensing If you intend to have your port merged into the main Mono distribution, keep in mind that you must grant Novell permission to redistribute your work under other licenses other than the LGPL. This means that you must be the owner of any code contributed to Novell and that you are in a position to sign such an agreement. You can also license your changes under the X11/MIT license, instead of signing a copyright assignment. Thanks, - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] atomic.h
On Mon, 2007-07-16 at 11:52 +0200, Andreas Färber wrote: Hello, With the growing number of supported architectures wouldn't it make sense to split up atomic.h like the mini files into atomic-ppc.h etc.? The whole file is a series of mutually exclusive conditional sections. I don't have a problem with this, apart from losing svn history in the chunks that are split out. - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Threading.Thread.ApartmentState Patch
On Wed, 2007-05-02 at 15:57 -0400, Jonathan Chambers wrote: Hello, Here is a patch to implement Thread.ApartmentState related methods/properties. The methods/properties behave correctly on all platforms, but only call CoInitialize on Windows. I will also commit the change detailed in bug 80798 before/with this patch else the error described in the bug becomes much more frequent on windows (the change may fix bug 77075). Please review. Both patches look fine to me. - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] File accesses in ported applications
Wed May 02 11:32:40 @grendel Dick: do you think it would be possible to write a file analyzer? Wed May 02 11:32:43 @grendel file access analyzer Wed May 02 11:33:18 @Dick how about an aspx-lint that checks for this sort of thing? Wed May 02 11:33:37 @grendel Dick: the lint would have to be either a monitor app or inside Mono Wed May 02 11:33:42 @grendel it's not aspx-specific, IMHO Wed May 02 11:33:48 @Dick i was thinking separate app Wed May 02 11:33:52 @grendel it can affect WF apps too Wed May 02 11:33:59 @Dick anyway, what would your file access analyzer do? Wed May 02 11:34:26 @grendel it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name Wed May 02 11:34:35 @grendel e.g. someFile.txt, somefIle.txt etc Wed May 02 11:34:41 @Dick hmm Wed May 02 11:34:46 @Dick that could be handy Wed May 02 11:34:46 @grendel and would warn about the method, file, line where it happened Wed May 02 11:34:52 @grendel and output a report Wed May 02 11:34:59 @grendel it would be a great aid in porting Wed May 02 11:35:08 @Dick yeah Wed May 02 11:35:21 @grendel it could also look at the disk and check if there are files of the same flatten names in the same dir Wed May 02 11:35:22 @Dick i wonder if it would fit inside gendarme? Wed May 02 11:35:26 @grendel and make that a critical working Wed May 02 11:35:27 @Dick or moma Wed May 02 11:35:42 @grendel hm, moma would be a better choice I think Wed May 02 11:36:02 @grendel Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime Wed May 02 11:36:08 @grendel and enable it along with IOMAP Wed May 02 11:36:22 @Dick yeah, thats definitely possible Wed May 02 11:36:30 @grendel it would take care of all the cases Wed May 02 11:36:50 @grendel you could output the diags to console on *nix and to the event sink on windows Wed May 02 11:36:54 @Dick the problem would be noticing the output if its was stuck there Wed May 02 11:37:22 @grendel yeah, but you can't do much about it Wed May 02 11:37:29 @grendel people must know the feature exists and where to find it Wed May 02 11:37:35 @grendel we put it in the docs and that's it Wed May 02 11:37:56 @Dick personally i'd put it in moma first and the runtime second Wed May 02 11:37:57 @grendel you could even enable it conditionally Wed May 02 11:38:08 @grendel Dick: that might be a good idea for testing, yeah Wed May 02 11:38:19 @Dick it would have to be conditional, saving all the filenames would be time and memory consuming Wed May 02 11:38:30 @grendel true Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this Wed May 02 11:39:13 @grendel Dick: cut-n-paste and mail to them? :) Wed May 02 11:39:26 @Dick hopefully they might notice their names light up :) Wed May 02 11:39:41 @Dick sending it to xml or mono-devel would be good though Wed May 02 11:39:50 @grendel miguel: read what's above this line :) Wed May 02 11:39:56 @grendel jpobst|gone: read what's above this line :) Wed May 02 11:40:21 @grendel Dick: that's true signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_shm_semaphores_init
On Tue, 2006-12-19 at 19:49 +0100, Joachim Ante wrote: It's on my todo list, as is the rest of bug 78739. Glad to hear that. Any idea when that will be done? No estimate at the moment. - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_shm_semaphores_init
On Tue, 2006-12-19 at 17:40 +0100, Joachim Ante wrote: Hi, I have a customer who has some trouble launching Unity, it seems monotakes up all processing power while starting up and keeps printing printing the following message. ** (process:2473): CRITICAL **: _wapi_shm_semaphores_init: semget error: No space left on device. Try deleting some semaphores with ipcs and ipcrm He says he has 100 gigabyte of free disk space. Any idea on how this can happen and how to fix it? The semaphore group that mono uses to synchronise access to the shared memory is being leaked (the last mono instance using it tries to delete it, but if it terminates abnormally it wont get the chance.) He needs to run ipcs -s and delete the semaphores that look like 0x4d036b25 156139526 dick 6008 (the fingerprint numbers are the 600 perms and 8 nsems) with ipcrm. - Dick PS. Being able to disable .wapi completely with a compiler flag would be really useful It's on my todo list, as is the rest of bug 78739. signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] newbie installing 1.1.16 onto SUSE 10.1
On Tue, 2006-07-11 at 19:16 +0100, mike horsley wrote: We have successfully compiled a basic “hello world” app and run it but when we add a reference to System.Data into the application, we get the compilation error that the type or namespace “Data” (or if we try “Xml”) does not exist in the name “System”. We’ve looked at the environment variables (PATH, MONO_PATH) and suspect this to be the problem because none are set. Have you added -reference:System.Data.dll to the mcs command line? - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .Net 2.0 Socket class
On Tue, 2006-06-27 at 16:43 +0530, Sridhar Kulkarni wrote: Hi, Attached is a diff file which contains .Net 2.0 Methods and Properties for Socket class. Please review it and let me know your comments. It's impossible to review this patch, as it looks like you've changed the line endings and therefore diff things every line has changed. Please redo the diff with the -wBb options to ignore whitespace changes. Thanks, - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Multiple Segfaults on mono 1.1.13.6
On Tue, 2006-05-16 at 16:08 +1000, [EMAIL PROTECTED] wrote: Hi all, I am getting a segfault with the mono runtime, and since I couldn't find it in bugzilla, thought I would check with the list if it has been fixed. Unfortunately, the program is proprietary, so I cannot hand out the source. If more details are required however, I can try and isolate it more ... Other important details are that I compile the program using the Microsoft compiler ... I have not tested it with the mono compiler. The program loads some config, connects to a network socket via an asynchronous tcp connection, does a bunch of things, and then exits. It segfaults if I call Environment.Exit(1), rather than exiting cleanly. I think it does not segfault when I explicitly Disconnect the socket before exiting. Yeah, ugly code not to disconnect, but it shouldn't crash the runtime ... Environment.Exit() causing a crash rings a bell, but I can't think of the specifics right now. This is what the backtrace looks like: #0 0x006becae in __pthread_mutex_lock (mutex=0x74c008) at pthread_mutex_lock.c:76 #1 0x08108242 in mono_once () #2 0x080da7bf in mono_jit_info_table_find () #3 0x0813ba64 in mono_codegen () #4 signal handler called #5 0x080a5222 in mono_thread_pool_remove_socket () #6 0x080a42e3 in mono_debug_address_from_il_offset () #7 0x08099ff2 in mono_thread_get_tls_offset () #8 0x080f5227 in mono_environment_exitcode_set () #9 0x08113945 in GC_end_blocking () #10 0x006bd341 in start_thread (arg=0x1963bb0) at pthread_create.c:261 #11 0x004176fe in ?? () from /lib/tls/libc.so.6 That backtrace looks fairly garbled to me. Is this extracted from a core dump or did you run your app through gdb? Ah, actually, after I change the code to explicitly call Disconnect on the sockets before calling Environment.Exit(1), I am now getting a different segfault ... That trace doesn't help much either. mono --version Mono JIT compiler version 1.1.13.6, (C) 2002-2005 Novell, Inc and Contributors. Could you try a newer version (either later 1.1.13 or head), compiled with debugging symbols? And if you extracted the backtrace from a core dump, running it in gdb might generate better information. You need to tell gdb: handle SIGPWR SIGXCPU nostop noprint pass before you start executing. The machine has 4 intel xeon cpus. Does anything change if you run on a single processor machine? - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: What would you like to see in Mono? [.wapi-less config]
On Sun, 2006-04-09 at 16:50 +0200, Joachim Ante wrote: So will such a configure variable be added? Or will MONO_DISABLE_SHM be reintroduced? Yes - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: [PATCH] ShellExecuteEx ProcessId support for Windows 2000 and Windows XP RTM
On Tue, 2006-04-04 at 12:01 +0200, Kornél Pál wrote: Could someone please review this patch. I was on holiday, and you didn't seem too confident about this patch anyway; but here goes: The GetProcessId check should remain in configure.in, and HAVE_GETPROCESSID be used by the code to check if its available or not. Remember, check for features not platforms. Check that interdependencies between msvcrt.dll and ntdll.dll can be _reliably_ solved by the link order. Then I'll review an updated patch. Thanks, - Dick signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [PATCH] Verbose message for disk full error.
On Wed, 2006-02-22 at 12:49 +0100, Jörg Rosenkranz wrote: Hi Dick, The attached patch adds a verbose exception to error 39 (disk full). Is it save to commit this change? Looks good to me. Thanks, - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [PATCH] Map SocketFlags enum to native flags
On Wed, 2006-02-01 at 22:03 +0530, Ankit Jain wrote: But this means that a #include mono/metadata/socket-io.h is required in mono/io-layer/sockets.c, as the mapping of flags is done in io-layer/sockets.c (_wapi_recv etc). Am not sure whether this dependency is acceptable. You need to do the conversion from managed flags to native in the metadata/socket-io.c file, like all the other enum mappings. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono_thread_attach/mono_thread_detach not threadsafe?
On Mon, 2006-01-30 at 21:36 -0800, Allan Hsu wrote: One thing I forgot to mention: This code will not print the warning on OS X or segfault on Linux if you run it with GC_DONT_GC=1. The finalizer thread doesn't do anything with that environment variable set. I'll have a look at the sample you code you posted in the other mail. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_handle_unref: what does it mean?
On Sat, 2006-01-28 at 17:26 -0800, Allan Hsu wrote: Can anybody tell me what the meaning of this console output is? ** (process:12367): WARNING **: _wapi_handle_unref: Attempting to unref unused handle 0xcb7 It means something in the runtime has lost track of its handles and is attempting to CloseHandle more times than the handle was opened. More specifically, I'd like to know just how bad it is and what sorts of things can cause it. The warning itself is harmless (the CloseHandle code ignores an unref attempt in these circumstances) but it is a symptom of a bug - code somewhere is relying on a handle that has vanished from underneath it. If you want to try and figure out where the bug is, run mono inside gdb and put a breakpoint on the g_warning in handles.c then get a backtrace when the breakpoint is hit. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .WAPI folder
On Thu, 2006-01-19 at 16:52 +0100, Matthijs ter Woord wrote: When i would have a single application hosting several appdomains with different services (think of http, ftp, smtp, pop3, others), how would the .wapi directory contents behave then? Makes no difference - ie the part of my reply you snipped still applies. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .WAPI folder
On Mon, 2006-01-16 at 18:22 +0100, Matthijs ter Woord wrote: Hi, Is it desirable to have the .wapi directory on a in-memory filesystem? I mean, when having dozens of applications running (like web servers = xsp, ftp servers, and others), what size would the .wapi folder be in the worsed scenario? At the moment the contents has a fixed size. In the fairly near future it will be changed to have a much smaller initial size but expanding the files as necessary. In the worst case it would just fill the available filesystem space, so the answer seems to be give your ramfs an adequate but limited size. In normal operation (ie, without using the MONO_SHARED_DIR environment variable) there is one .wapi directory per user, not per application. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sharing violation on log4net
On Mon, 2005-11-28 at 17:22 -0600, Carlos Solorzano wrote: I am getting a sharing violation exception a lot since upgrading to mono 1.1.10, the code used to work a lot more often without that exception on mono 1.1.9.2 The file handling code should be the same between those two releases, as far as I can remember. What its really bothering me now is that the sharing violation not only ocurrs after mono is completely closed and restarted but I am even getting it after system reboots, it makes no sense why that would happen. The share data is stored in a file in ~/.wapi. If it finds a record for the file you are trying to open, it tries to check /proc for mono processes that have that file open. Look in mono/io-layer/handles.c:_wapi_handle_check_share to see what it's doing, and you might be able to watch it in gdb to see why it's failing. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] windows shares
On Fri, 2005-11-25 at 12:40 +0200, Anton Andreev wrote: How does Mono handles the following on Linux? name=@\\store\work.zip; fs_in=new FileStream(name,FileMode.Open,FileAccess.Read,FileShare.Read); mono will try to open the file /store/work.zip We do not link mono with samba, and have no plans to do so. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: [Mono-patches] r44192 - trunk/mcs/class/System/System.Net.Sockets
On Mon, 2005-05-09 at 16:52 -0600, Gonzalo Paniagua Javier wrote: On Mon, 2005-05-09 at 09:07 +0100, Dick Porter wrote: Given how fragile thread aborting is, even without this race condition this might get ugly. I can't think of a better solution offhand though... Did you see the C test case in the bug report? There seems to be no other way of closing from one thread if other is accepting than through a signal that interrupts the call. I didn't look at it before, but have now. One possible answer might be to put the socket into non-blocking mode while it is accept()ing. accept() then returns EAGAIN (or EWOULDBLOCK) when there are no connections ready to be accepted, and EBADF when the socket closes. I've attached a new version of your C test (I think you should have been waiting for cond2 in the poll test too, but it didn't seem to make any difference.) We would have to make sure to track the requested blocking state. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: [PATCH] Bug 74586 (and other oddities with the beta)
On Thu, 2005-04-14 at 10:10 +0200, Bill Middleton wrote: Here's a better patch. I hope I'm getting closer here... :) I fixed this yesterday :) - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [OT] Netiquette in the list
On Fri, 2005-04-01 at 20:31 +0200, Valient Gough wrote: Uh oh, the standards police have arrived. This is a public forum, so format your messages as you wish, and wear your fireproof undies. The people with the answers have very limited time; time spent wading through HTML-formatted mails (as Paolo says, a good indication of lack of meaningful content) or paging through screenfulls of unsnipped quoting trying to match context is time spent not hacking on the code. If you want your question to the list answered, you need to make it as easy as possible to see what the problem is. That means providing it in the format generally expected (ie meaningful subject, concise inline quoting, plain text.) Otherwise it's likely that the mail will just be deleted unread while we're scanning through the list. Indeed, if you can't be bothered to do that why should we bother to respond? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
