Re: [Mono-dev] Process.GetCurrentProcess().Modules crashes on Mac OS X Snow Leopard
Please file a bug about this. On Mon, Aug 24, 2009 at 6:27 PM, Tom Philpot wrote: > We just discovered this issue with Mono 2.4.2.3 on Mac OS X under the most > recent Snow Leopard build. > > System.Diagnostics.Process.GetCurrentProcess().Modules fails with a crash. > > Snow:MacOS dev$ csharp > Mono C# Shell, type "help;" for help > > Enter statements below. > csharp> System.Diagnostics.Process.GetCurrentProcess().Modules; > Stacktrace: > > at (wrapper managed-to-native) > System.Diagnostics.Process.GetModules_internal (intptr) <0x4> > at (wrapper managed-to-native) > System.Diagnostics.Process.GetModules_internal (intptr) <0x> > at System.Diagnostics.Process.get_Modules () <0x0001d> > at (wrapper remoting-invoke-with-check) > System.Diagnostics.Process.get_Modules () <0x> > at Class0.Host (object&) <0x00015> > at Mono.CSharp.Evaluator.Evaluate (string,object&,bool&) <0x00086> > at Mono.CSharpShell.Evaluate (string) <0x00031> > at Mono.CSharpShell.ReadEvalPrintLoopWith (Mono.CSharpShell/ReadLiner) > <0x00077> > at Mono.CSharpShell.ReadEvalPrintLoop () <0x0008a> > at Mono.CSharpShell.Run (string[]) <0x00017> > at Mono.Driver.Main (string[]) <0x0016d> > at (wrapper runtime-invoke) Mono.Driver.runtime_invoke_int_object > (object,intptr,intptr,intptr) <0x> > Abort trap > Snow:MacOS dev$ > > ___ > 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] Hacking mono to make it more deterministic
Hi, Lucas. You might consider creating a version of Hashtable and Dictionary with an iterator that depends on the order on which the elements are introduced (and not upon the hash value of the elements). This will introduce some overhead in performance and memory (maintaining a doubly linked list of nodes) but will give you the determinism you seek. Eyal. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Lucas Meijer Sent: Monday, August 24, 2009 4:13 PM To: 'mono-devel-list' Subject: [Mono-dev] Hacking mono to make it more deterministic Hey, At Unity we have this internal testing system where we 1) play a game, and record all inputs 2) can replay that game, based on the recorded inputs 3) whenever we do a checkin on our sourcecode, we run all games in the testing setup against this new unity build, by making screenshots every 5 seconds, and comparing those to the previous run. This has proven to be very useful, as it finds regressions in our users games that we had not anticipated when committing a certain change to the unity codebase. Currently, not all games are playing back deterministically on a single unity build. We don't think we'll ever reach full deterministicality (is that a word?) for 100% of our games, but the higher we get the number, the better we like it. In order to do this, we mock out things like System.Random, DateTime.Now, to return the recorded values. A frequent case where games fail to run identically is when our users iterate over a dictionary which has a custom type as its key. Since the dictionary uses GetHashCode() internally, and Object.GetHashCode() is based on the memory address of the object, it means that the order in which the KeyValuePair's get returned can differ per run. Naturally our users shouldn't be doing this. But they do, as they don't realize that consistent ordering of iterating over a dictionary isn't guaranteed. it just works most of the time so most people don't notice. I didn't realize this myself untill I started investigating this issue :) I'm looking for advice on what would be the best solution to this. So far the best idea I've came up with is to make mono_object_hash just return 0. That probably has some severe performance implications, but we can live with those. I'm hoping this will only make things go a lot slower, but wanted to ask this list: - if I should expect other problems than slowdown - if you can think of a better/different way to make our users code deterministic Thanks, Lucas ___ 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] Hacking mono to make it more deterministic
Forcing sys.object::hash_code to be zero will result in insertion order to Dictionary and cause all operations to be linear. On Mon, Aug 24, 2009 at 10:13 AM, Lucas Meijer wrote: > Hey, > > At Unity we have this internal testing system where we > > 1) play a game, and record all inputs > 2) can replay that game, based on the recorded inputs > 3) whenever we do a checkin on our sourcecode, we run all games in the > testing setup against this new unity build, by making screenshots every > 5 seconds, and comparing those to the previous run. > > This has proven to be very useful, as it finds regressions in our users > games that we had not anticipated when committing a certain change to > the unity codebase. > > Currently, not all games are playing back deterministically on a single > unity build. We don't think we'll ever reach full deterministicality (is > that a word?) for 100% of our games, but the higher we get the number, > the better we like it. > > In order to do this, we mock out things like System.Random, > DateTime.Now, to return the recorded values. > > A frequent case where games fail to run identically is when our users > iterate over a dictionary which has a custom type as its key. Since the > dictionary uses GetHashCode() internally, and Object.GetHashCode() is > based on the memory address of the object, it means that the order in > which the KeyValuePair's get returned can differ per run. > > Naturally our users shouldn't be doing this. But they do, as they don't > realize that consistent ordering of iterating over a dictionary isn't > guaranteed. it just works most of the time so most people don't notice. > I didn't realize this myself untill I started investigating this issue :) > > I'm looking for advice on what would be the best solution to this. > > So far the best idea I've came up with is to make mono_object_hash just > return 0. That probably has some severe performance implications, but we > can live with those. I'm hoping this will only make things go a lot > slower, but wanted to ask this list: > > - if I should expect other problems than slowdown > - if you can think of a better/different way to make our users code > deterministic > > Thanks, Lucas > ___ > 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] Process.GetCurrentProcess().Modules crashes on Mac OS X Snow Leopard
We just discovered this issue with Mono 2.4.2.3 on Mac OS X under the most recent Snow Leopard build. System.Diagnostics.Process.GetCurrentProcess().Modules fails with a crash. Snow:MacOS dev$ csharp Mono C# Shell, type "help;" for help Enter statements below. csharp> System.Diagnostics.Process.GetCurrentProcess().Modules; Stacktrace: at (wrapper managed-to-native) System.Diagnostics.Process.GetModules_internal (intptr) <0x4> at (wrapper managed-to-native) System.Diagnostics.Process.GetModules_internal (intptr) <0x> at System.Diagnostics.Process.get_Modules () <0x0001d> at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.get_Modules () <0x> at Class0.Host (object&) <0x00015> at Mono.CSharp.Evaluator.Evaluate (string,object&,bool&) <0x00086> at Mono.CSharpShell.Evaluate (string) <0x00031> at Mono.CSharpShell.ReadEvalPrintLoopWith (Mono.CSharpShell/ReadLiner) <0x00077> at Mono.CSharpShell.ReadEvalPrintLoop () <0x0008a> at Mono.CSharpShell.Run (string[]) <0x00017> at Mono.Driver.Main (string[]) <0x0016d> at (wrapper runtime-invoke) Mono.Driver.runtime_invoke_int_object (object,intptr,intptr,intptr) <0x> Abort trap Snow:MacOS dev$ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hacking mono to make it more deterministic
On Mon, Aug 24, 2009 at 1:13 PM, Lucas Meijer wrote: > - if you can think of a better/different way to make our users code > deterministic Perhaps use a PRNG (always with the same starting seed) for the hashcode of an object, and store the hash as a member in Object itself. Clearly this wouldn't be a good idea for "real" mono, but it would make things deterministic with regard to the creation order of objects, at least. Of course, if you use any threading, true determinism is virtually impossible. Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Hacking mono to make it more deterministic
Hey, At Unity we have this internal testing system where we 1) play a game, and record all inputs 2) can replay that game, based on the recorded inputs 3) whenever we do a checkin on our sourcecode, we run all games in the testing setup against this new unity build, by making screenshots every 5 seconds, and comparing those to the previous run. This has proven to be very useful, as it finds regressions in our users games that we had not anticipated when committing a certain change to the unity codebase. Currently, not all games are playing back deterministically on a single unity build. We don't think we'll ever reach full deterministicality (is that a word?) for 100% of our games, but the higher we get the number, the better we like it. In order to do this, we mock out things like System.Random, DateTime.Now, to return the recorded values. A frequent case where games fail to run identically is when our users iterate over a dictionary which has a custom type as its key. Since the dictionary uses GetHashCode() internally, and Object.GetHashCode() is based on the memory address of the object, it means that the order in which the KeyValuePair's get returned can differ per run. Naturally our users shouldn't be doing this. But they do, as they don't realize that consistent ordering of iterating over a dictionary isn't guaranteed. it just works most of the time so most people don't notice. I didn't realize this myself untill I started investigating this issue :) I'm looking for advice on what would be the best solution to this. So far the best idea I've came up with is to make mono_object_hash just return 0. That probably has some severe performance implications, but we can live with those. I'm hoping this will only make things go a lot slower, but wanted to ask this list: - if I should expect other problems than slowdown - if you can think of a better/different way to make our users code deterministic Thanks, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .NET / Mono runtime multi-cast differences.
The central problem is described in the sentence "Unless the Socket.Bind
operation is modified to bind to a different end
point based on the runtime, no packets will be received."
The meaning of listenChannel and listenEndpoint can be inferred from
their use in subsequent statements, but for sake of clarity, I should
have explained them better.
listenChannel = An end point containing the multicast address / port
combination which you are interested in joining / subscribing to.
listenEndpoint = An end point containing the interface address /
multicast port combination of the network interface on which you would
like to receive the packets.
Thanks
Jim
Alan McGovern wrote:
> Hi,
>
> Unless I'm missing something, you haven't actually described what the
> problem is. Nor have you mentioned what exactly happens on windows,
> what happens on linux and what you actually expected to happen. Your
> example also appears to be missing information which might help figure
> out what issue it is you're seeing, what are listenChannel and
> listenEndpoint?
>
> Alan.
>
> On Mon, Aug 24, 2009 at 3:20 AM, James P Michels III
> mailto:james.p.mich...@gmail.com>> wrote:
>
> I have observed a difference in behavior between the Mono runtime and
> .NET runtime with respect to multi-cast support.
>
> Unless the Socket.Bind operation is modified to bind to a
> different end
> point based on the runtime, no packets will be received. The
> workaround
> that I am using is shown in the attached code section.
>
> I took a look at Mono's source code. Additionally, I wrote a short C
> program with the equivalent functionality. The C version for Linux
> exhibits the same behavior. It is my impression that the behavior
> is due
> to differences between the Windows socket implementation and the Linux
> socket implementation. It is also my impression that these differences
> are being realized by both the .NET and Mono runtime which ultimately
> consume them.
>
> I have 2 questions.
>
> 1) Am I wrong? Is there a runtime agnostic way to do this? (Binding to
> IPAddress.Any does not work on Windows to my knowledge)
>
> 2) If I am not wrong, what steps, if any, should be taken to resolve
> these differences?
>
> Thanks
> Jim
>
> -begin code sample
>
>listenSocket = new Socket(AddressFamily.InterNetwork,
> SocketType.Dgram, ProtocolType.Udp);
>listenSocket.SetSocketOption(SocketOptionLevel.Socket,
> SocketOptionName.ReuseAddress, true);
>
>if (IsMonoRuntime())
>{
>listenSocket.Bind(listenChannel);
>}
>else
>{
>listenSocket.Bind(listenEndpoint);
>}
>
>listenSocket.SetSocketOption(SocketOptionLevel.IP,
> SocketOptionName.MulticastInterface,
> listenInterface.GetAddressBytes());
>listenSocket.SetSocketOption(SocketOptionLevel.IP,
> SocketOptionName.AddMembership, new
> MulticastOption(listenChannel.Address, listenInterface));
>
>
> -end code sample
> ___
> 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] Cause libgc to return some unused memory to the system
We tested it on our Plastic SCM load tests and it worked as expected. pablo www.plasticscm.com Dick Porter wrote: > 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 > > > > > ___ > 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] .NET / Mono runtime multi-cast differences.
Hi,
Unless I'm missing something, you haven't actually described what the
problem is. Nor have you mentioned what exactly happens on windows, what
happens on linux and what you actually expected to happen. Your example also
appears to be missing information which might help figure out what issue it
is you're seeing, what are listenChannel and listenEndpoint?
Alan.
On Mon, Aug 24, 2009 at 3:20 AM, James P Michels III <
james.p.mich...@gmail.com> wrote:
> I have observed a difference in behavior between the Mono runtime and
> .NET runtime with respect to multi-cast support.
>
> Unless the Socket.Bind operation is modified to bind to a different end
> point based on the runtime, no packets will be received. The workaround
> that I am using is shown in the attached code section.
>
> I took a look at Mono's source code. Additionally, I wrote a short C
> program with the equivalent functionality. The C version for Linux
> exhibits the same behavior. It is my impression that the behavior is due
> to differences between the Windows socket implementation and the Linux
> socket implementation. It is also my impression that these differences
> are being realized by both the .NET and Mono runtime which ultimately
> consume them.
>
> I have 2 questions.
>
> 1) Am I wrong? Is there a runtime agnostic way to do this? (Binding to
> IPAddress.Any does not work on Windows to my knowledge)
>
> 2) If I am not wrong, what steps, if any, should be taken to resolve
> these differences?
>
> Thanks
> Jim
>
> -begin code sample
>
>listenSocket = new Socket(AddressFamily.InterNetwork,
> SocketType.Dgram, ProtocolType.Udp);
>listenSocket.SetSocketOption(SocketOptionLevel.Socket,
> SocketOptionName.ReuseAddress, true);
>
>if (IsMonoRuntime())
>{
>listenSocket.Bind(listenChannel);
>}
>else
>{
>listenSocket.Bind(listenEndpoint);
>}
>
>listenSocket.SetSocketOption(SocketOptionLevel.IP,
> SocketOptionName.MulticastInterface, listenInterface.GetAddressBytes());
>listenSocket.SetSocketOption(SocketOptionLevel.IP,
> SocketOptionName.AddMembership, new
> MulticastOption(listenChannel.Address, listenInterface));
>
>
> -end code sample
> ___
> 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] Cross platform USB programming
The error is clear, LibUsbDotNet.UsbGlobals.get_HasWinUsbDriver , so the guy wrapped only native WIN32 code, which cannot work on other platform like Linux and so on, i already try libusbdonet and never have it working , i asked to the author (see sourceforge project forum) to have it working under Linux, so ICsharp is obsolete , why ?!!, they invented a new USB protocol :-) Hoho, i post this remark really long time ago and it seems the author disable the forum 2009/7/16 Napcaia : > > ICSharp usb lib is obsolete, all the work it's been done in LibUsbDotNet, > you can download it at http://sourceforge.net/projects/libusbdotnet/ and the > example code is at http://libusbdotnet.sourceforge.net/V2/Index.html > > I have try the example code but it doesn't work, I have the following > message > " > Finding your device.. > > Unhandled Exception: System.ArgumentException: An empty file name is not > valid. > at System.IO.FileSystemInfo.CheckPath (System.String path) [0x0] > at System.IO.DirectoryInfo..ctor (System.String path, Boolean > simpleOriginalPath) [0x0] > at System.IO.DirectoryInfo..ctor (System.String path) [0x0] > at (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo:.ctor > (string) > at LibUsbDotNet.UsbGlobals.get_HasWinUsbDriver () [0x0] > at LibUsbDotNet.UsbGlobals.get_AllDevices () [0x0] > at Examples.GettingStarted.Main (System.String[] args) [0xa] in > /home/eder/Projects/Prueba/Prueba/Main.cs:23 > " > > I have a post with that, if i get the solution i tell you. > > Greetings from Colombia. > -- > View this message in context: > http://www.nabble.com/Cross-platform-USB-programming-tp24515653p24521064.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 > -- Cordially. Small Eric Quotations of the days: --- I have no special talents. I am only passionately curious ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
