[Mono-dev] ServicePoint.CheckAvailableForRecycling crashes in Mono 3.4.0
We’ve just released a beta of our app with Mono-3.4.0 embedded in it and we’re having some crashes due to the latest ServicePoint changes it appears. I’ve opened two new bugs with stack traces we¹ve seen: https://bugzilla.xamarin.com/show_bug.cgi?id=19822 https://bugzilla.xamarin.com/show_bug.cgi?id=19823 If we can get reliable repros of either (or both) of those bugs in small test programs, we’ll add them to the bug reports. Seems like there is at least one other reported bug with this code as well: https://bugzilla.xamarin.com/show_bug.cgi?id=18814 Thanks, Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] I: Re: System.Diagnostics.Process.Start() crashes when trying to allocate more than 255 processes
Might it have to do with the fact that Mono only allows 256 shared handles? See _WAPI_HANDLE_INITIAL_COUNT in wapi-private.h and the "/* FIXME: grow the arrays */" in handles.c _wapi_handle_real_new(). We ran into a problem like this on a build box that exec'd a lot of processes but we worked around it by using GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); to clean up the handles. Tom On 6/13/11 8:05 AM, "fco...@libero.it" wrote: >Versions: both mono 2.10 and 2.8. I think 2.4 has the same problem as >well. >Architecture: both x86 32 bit and 64 bit >OS: Redhat EL 5.4 >Ubuntu 10.04 >Stack trace: just run the example code. It's self contained. > >>>Messaggio originale >>>Da: robe...@gmx.net >>>Data: 13/06/2011 16.14 >>>A: >>>Ogg: Re: [Mono-dev] System.Diagnostics.Process.Start() crashes when >>>trying >to >>allocate more than 255 processes >>> >>>On 13.06.2011 16:10, fco...@libero.it wrote: Dear all, my linux application needs to start a big number (400) of processes. >Each >>process is a mono application. I found the when trying to run more then 255 processes the runtime >>generates an exception. >>> >>>Mono version? Architecture? Exception's stack trace? >>> >>>Robert >>> >>>___ >>>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] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1
One other note: I was also able to reproduce this on using the latest tarball of Mono 2.10.2 on a quad-core Xeon running Windows 7, but only 1 out of 4 attempts. From: Tom Philpot mailto:tom.phil...@logos.com>> Date: Thu, 19 May 2011 08:50:27 -0700 To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" mailto:mono-devel-list@lists.ximian.com>> Subject: Re: [Mono-dev] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1 So, after running an automated git bisect, it turns out that commit 50a295ac1be (https://github.com/mono/mono/commit/50a295ac1becc5c0927917644a1b246b4c8e945b#mcs/class/System/System.Net.Sockets/Socket_2_1.cs) caused the breakage on the dual-core Macs we're using. Unfortunately, fixing it is not as simple as "git revert 50a295ac1be" as there are some conflicts and once those are resolved, Socket.EndReceive ends up getting called twice. Any thoughts? From: Tom Philpot mailto:tom.phil...@logos.com>> Date: Tue, 17 May 2011 12:16:10 -0700 To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" mailto:mono-devel-list@lists.ximian.com>> Subject: WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1 Since switching to 2.10.1 for our app, we're seeing a lot more Read() timeouts when downloading large files (greater than 50 MB or so). I've created a small test program that reproduces the behavior. We've noticed that this bug is that it is more likely to happen on users systems who only have 2 cores. On machines with 4 or more cores, bug does not manifest itself as much. Running the test program under 2.6.x works fine, but under 2.10.1 it fails more often than not for me when I run on my MacBook. It runs fine on my MacPro whether I use 2.6.x or 2.10.1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1
So, after running an automated git bisect, it turns out that commit 50a295ac1be (https://github.com/mono/mono/commit/50a295ac1becc5c0927917644a1b246b4c8e945b#mcs/class/System/System.Net.Sockets/Socket_2_1.cs) caused the breakage on the dual-core Macs we're using. Unfortunately, fixing it is not as simple as "git revert 50a295ac1be" as there are some conflicts and once those are resolved, Socket.EndReceive ends up getting called twice. Any thoughts? From: Tom Philpot mailto:tom.phil...@logos.com>> Date: Tue, 17 May 2011 12:16:10 -0700 To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" mailto:mono-devel-list@lists.ximian.com>> Subject: WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1 Since switching to 2.10.1 for our app, we're seeing a lot more Read() timeouts when downloading large files (greater than 50 MB or so). I've created a small test program that reproduces the behavior. We've noticed that this bug is that it is more likely to happen on users systems who only have 2 cores. On machines with 4 or more cores, bug does not manifest itself as much. Running the test program under 2.6.x works fine, but under 2.10.1 it fails more often than not for me when I run on my MacBook. It runs fine on my MacPro whether I use 2.6.x or 2.10.1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1
Since switching to 2.10.1 for our app, we're seeing a lot more Read() timeouts when downloading large files (greater than 50 MB or so). I've created a small test program that reproduces the behavior. We've noticed that this bug is that it is more likely to happen on users systems who only have 2 cores. On machines with 4 or more cores, bug does not manifest itself as much. Running the test program under 2.6.x works fine, but under 2.10.1 it fails more often than not for me when I run on my MacBook. It runs fine on my MacPro whether I use 2.6.x or 2.10.1 DownloadTest.cs Description: DownloadTest.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Process.Start and Paths with single quote
It seems that a Process Start()'d from a ProcessInfo with a
WorkingDirectory that contains one single quote (') causes problems for
Mono.
using System;
using System.IO;
using System.Diagnostics;
namespace SingleQuoteFolderProcessTest
{
class MainClass
{
public static void Main (string[] args)
{
ProcessStartInfo info = new ProcessStartInfo();
info.UseShellExecute = false;
// hello world is a trival "Hello World" binary - left as an exercise
for the reader
info.FileName = "helloworld";
info.WorkingDirectory =
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal),
"iWork '09");
using (Process.Start(info))
{
}
}
}
}
Interestingly enough, the following works fine
string dir =
Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal),
"iWork '09");
string exe = Path.Combine(dir, "helloworld");
using (Process.Start(exe))
{
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.Start and WaitForExit on MacOS X
Apparently, the bug I filed was marked as a duplicate of this WONTFIX bug: https://bugzilla.novell.com/show_bug.cgi?id=668867 According to the resolution of that bug, I just need to enable shared handles. Unless I'm doing something wrong, enabling shared handles should be as simple as "MONO_ENABLE_SHM=1 mono ProcessTest.exe", right? That doesn't seem to fix the issue. We're finding that running CruiseControl.Net under Mono creates zombies because the processes aren't waited for, and this happened even in 2.6, where IIRC, shared handles were enabled by default. Thanks, Tom On 3/15/11 2:15 PM, "Tom Philpot" wrote: >Submitted bug with a reproducible test case: >https://bugzilla.novell.com/show_bug.cgi?id=679936 > >On 3/15/11 12:26 PM, "Jonathan Pryor" wrote: > >>On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote: >>> I've discovered that Process.Start(ProcessStartInfo info) leaves child >>>processes hanging around until the parent process dies, unless you call >>>WaitForExit() on the child process. >>... >>> Is this a bug or by design? >> >>The problem is the Process.ExitCode property. There's no way to retrieve >>this value except through the waitpid(2) (and related) system calls, so >>the process can't be fully disposed just in case the ExitCode property >>will be accessed. >> >>That said, once the instance has been disposed, it shouldn't be necessary >>to keep anything open, and the child handles should be closed. Given that >>you _are_ using a `using` block, and thus disposing of the instance, it >>seems that this is likely a bug and that Process.Dispose() isn't fully >>closing all resources as it should. >> >>(For that matter, the Process finalizer should also be disposing of >>unmanaged resources, and it looks like that isn't the case either). >> >>Could you please file a bug? >> >>Thanks, >> - Jon >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.Start and WaitForExit on MacOS X
Submitted bug with a reproducible test case: https://bugzilla.novell.com/show_bug.cgi?id=679936 On 3/15/11 12:26 PM, "Jonathan Pryor" wrote: >On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote: >> I've discovered that Process.Start(ProcessStartInfo info) leaves child >>processes hanging around until the parent process dies, unless you call >>WaitForExit() on the child process. >... >> Is this a bug or by design? > >The problem is the Process.ExitCode property. There's no way to retrieve >this value except through the waitpid(2) (and related) system calls, so >the process can't be fully disposed just in case the ExitCode property >will be accessed. > >That said, once the instance has been disposed, it shouldn't be necessary >to keep anything open, and the child handles should be closed. Given that >you _are_ using a `using` block, and thus disposing of the instance, it >seems that this is likely a bug and that Process.Dispose() isn't fully >closing all resources as it should. > >(For that matter, the Process finalizer should also be disposing of >unmanaged resources, and it looks like that isn't the case either). > >Could you please file a bug? > >Thanks, > - Jon > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
> I do not know how you are compiling your OSX app but otool and >install_name_tool were very useful in my understanding of the embedding >process. If you linking against shared libraries and using install_name_tool, you'll also want to provide the linker flag "-headerpad_max_install_names". ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Process.Start and WaitForExit on MacOS X
Regarding this post on Mono-OSX http://go-mono.com/forums/#nabble-td3251954 and
some of my own issues with Process.Start() on MacOS X.
I've discovered that Process.Start(ProcessStartInfo info) leaves child
processes hanging around until the parent process dies, unless you call
WaitForExit() on the child process.
An alternative is to do something like this: (see above forum link for the rest
of the code that this applies to).
using (var ioreg = Process.Start(ioregInfo)) {
ioreg.EnableRaisingEvents = true;
EventHandler handler;
handler = (s,e) => { ioreg.Exited -= handler; ioreg.WaitForExit(); };
ioreg.Exited += handler;
// Do something with the process
}
If you don't call WaitForExit() in some way on the process, the child processes
hang around until the parent process dies and you end up with fork() returning
–1 with an EAGAIN error code because you'll have exceeded the maximum number of
processes allowed per uid.
Is this a bug or by design?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Named EventWaitHandles are not signaled across processes (Regression from 2.7)
After I hit send I realized Zoltan pointed me to the release notes for 2.8 where this is disabled by default. http://www.mono-project.com/Release_Notes_Mono_2.8#Shared_handles_are_disabled_by_default From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] On Behalf Of Tom Philpot [tom.phil...@logos.com] Sent: Friday, February 25, 2011 9:38 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Named EventWaitHandles are not signaled across processes (Regression from 2.7) In trying to upgrade from 2.6 to 2.8+, we've noticed a regression with Named EventWaitHandles not being set across processes. The bug appears in 2.8.1 and in master. If a thread in one process is waiting on a named EWH, and a thread in another process Set()'s the appropriately named EWH, the waiting thread is never notified. This used to work in 2.6/2.7. I've opened a bugzilla bug for this: https://bugzilla.novell.com/show_bug.cgi?id=675360 with the attached code which demonstrates the behavior. Build the code (gmcs –out:EventWaitHandleTest.exe Main.cs) Run "mono EventWaitHandleTest.exe listen" in one process Run "mono EventWaitHandleTest.exe signal" in another process ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Named EventWaitHandles are not signaled across processes (Regression from 2.7)
In trying to upgrade from 2.6 to 2.8+, we've noticed a regression with Named EventWaitHandles not being set across processes. The bug appears in 2.8.1 and in master. If a thread in one process is waiting on a named EWH, and a thread in another process Set()'s the appropriately named EWH, the waiting thread is never notified. This used to work in 2.6/2.7. I've opened a bugzilla bug for this: https://bugzilla.novell.com/show_bug.cgi?id=675360 with the attached code which demonstrates the behavior. Build the code (gmcs –out:EventWaitHandleTest.exe Main.cs) Run "mono EventWaitHandleTest.exe listen" in one process Run "mono EventWaitHandleTest.exe signal" in another process Main.cs Description: Main.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS1692: Invalid number warning for #pragma restore?
Attached the previous code sample to
https://bugzilla.novell.com/show_bug.cgi?id=657601 which reproduces the bug
described in that case.
From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Wed, 15 Dec 2010 10:54:47 -0800
To: "mono-devel-l...@ximian.com<mailto:mono-devel-l...@ximian.com>"
mailto:mono-devel-l...@ximian.com>>
Subject: [Mono-dev] CS1692: Invalid number warning for #pragma restore?
One more thing I'm seeing today. The following gives a CS1692 for line 3 below.
Is this expected behavior or a bug?
#pragma warning disable 1591
public class C {}
#pragma warning restore 1591
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0136 Error - C# parser bug (master)
Created bug for this issue. https://bugzilla.novell.com/show_bug.cgi?id=659970
From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Wed, 15 Dec 2010 10:36:58 -0800
To: Tom Philpot mailto:tom.phil...@logos.com>>,
"mono-devel-l...@ximian.com<mailto:mono-devel-l...@ximian.com>"
mailto:mono-devel-l...@ximian.com>>
Subject: Re: [Mono-dev] CS0136 Error - C# parser bug (master)
Just noticed I forgot a "using System;" at the top
If also, if you replace the {} from under if (!bValue) with an empty statement
(I.e. ;) the code compiles without error.
From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Wed, 15 Dec 2010 10:27:37 -0800
To: "mono-devel-l...@ximian.com<mailto:mono-devel-l...@ximian.com>"
mailto:mono-devel-l...@ximian.com>>
Subject: [Mono-dev] CS0136 Error - C# parser bug (master)
{
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CS1692: Invalid number warning for #pragma restore?
One more thing I'm seeing today. The following gives a CS1692 for line 3 below.
Is this expected behavior or a bug?
#pragma warning disable 1591
public class C {}
#pragma warning restore 1591
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0136 Error - C# parser bug (master)
Just noticed I forgot a "using System;" at the top
If also, if you replace the {} from under if (!bValue) with an empty statement
(I.e. ;) the code compiles without error.
From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Wed, 15 Dec 2010 10:27:37 -0800
To: "mono-devel-l...@ximian.com<mailto:mono-devel-l...@ximian.com>"
mailto:mono-devel-l...@ximian.com>>
Subject: [Mono-dev] CS0136 Error - C# parser bug (master)
{
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CS0136 Error - C# parser bug (master)
The following code gives a CS0136 error when it shouldn't (running today's git
master)
namespace N
{
public class C
{
public event EventHandler MyDelegate = delegate { };
internal void DoSomething (bool bValue)
{
if (!bValue)
{
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Too many open files when adding many embedded resources
Building Mono 2.9 from git master, we're encountering an issue where an
assembly with lots of embedded resources (approx 4000), where gmcs is throwing
"Too many open files exception".
The culprit seems to be that a new file handle is opened for every embedded
resource when it's added. Mono 2.6 doesn't have this problem, so it appears to
be a regression
Assembly.cs line 730:
if (res.IsEmbeded) {
var stream = File.OpenRead (res.FileName);
module.Builder.DefineManifestResource (res.Name, stream, res.Attributes);
} else {
Builder.AddResourceFile (res.Name, Path.GetFileName (res.FileName),
res.Attributes);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)
Attached is a patch which should fix the issue.
Submitted under MIT/X11 license.
From: Tom Philpot mailto:tom.phil...@logos.com>>
Date: Tue, 14 Dec 2010 13:52:37 -0800
To: "mono-devel-l...@ximian.com<mailto:mono-devel-l...@ximian.com>"
mailto:mono-devel-l...@ximian.com>>
Subject: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)
In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1,
entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to
fail.
Gmcs.exe fails with "CS0584: Internal compiler error: Collection is read-only"
(in ecore.cs:433) when this case is encountered.
I ran across this error while compiling our code with Mono 2.9 from master
today. I'm not sure how to reproduce the error, otherwise I'd have submitted a
test case.
diff --git a/mcs/mcs/membercache.cs b/mcs/mcs/membercache.cs
index 6561b28..9e409b3 100644
--- a/mcs/mcs/membercache.cs
+++ b/mcs/mcs/membercache.cs
@@ -231,7 +231,10 @@ namespace Mono.CSharp {
if (list.Contains (ce))
continue;
- list.Add (ce);
+ if (list is MemberSpec[])
+ list = new List ()
{ list[0], ce };
+ else
+ list.Add (ce);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)
In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1, entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to fail. Gmcs.exe fails with "CS0584: Internal compiler error: Collection is read-only" (in ecore.cs:433) when this case is encountered. I ran across this error while compiling our code with Mono 2.9 from master today. I'm not sure how to reproduce the error, otherwise I'd have submitted a test case. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Automatically generating a C wrapper library for a .NET assembly
Alan, We do something similar to this in our Mac application. We wrote a custom attribute which decorates the C# classes that we need to access from Objective-C. Then we wrote a program which reflects over our compiled .NET assemblies looking for our attribute then generates Objective-C wrappers for our classes. Unfortunately for you, our code is not open source, and since it's targeted to Obj-C, it's probably not all that useful anyway. But I did want you to know that it can be done, and it works rather well. On 12/4/10 12:00 AM, "Alan Broun" wrote: >Hi there, > >I have a need (or think I do) to call .NET code from a native C/C++ >application. > >I think that I can do this by creating a C library that hosts the Mono >runtime, >loads up the desired assembly and wraps the routines I want to call. > >Ideally though I'd like to be able to generate this C library >automatically >using reflection coupled with attributes to mark the routines I want to >export. > >My questions are > >- Is there an open source project out there that does this already? >I've >done some Googling but can't seem to find anything. >- If there isn't any open source code out there is that because it's a >rubbish approach? Can anyone think of any problems with the way I want to >call >managed code? > >Thanks in advance for your time. > >Regards > >Alan > >___ >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] Generic type parameter member lookup bug in 2.8.1
Using the latest code from git, I encountered another regression from 2.6
(similar to the problem I reported here:
https://bugzilla.novell.com/show_bug.cgi?id=653710). I discovered this in
mono-2-8 from git, but confirmed that it exists on the master too.
The following code fails to compile with a CS1061 error complaining that
Start() is not defined for W. In looking at the code, it appears that the
MemberCache.FindMembers (..) method only looks at the BaseType and not the
TypeArguments to determine which members should be available.
namespace Application
{
public class Z {}
public interface IGenericInterface
{
T Start { get; }
}
public class A
where Y : Z, IGenericInterface
where W : Y
{
protected void SomeOtherOperation (W w)
{
w.Start ();
}
}
public class Foo { public static void Main () {}}
}
I've already opened https://bugzilla.novell.com/show_bug.cgi?id=657797 for this
error.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Generic Constraints Regression in 2.8
https://bugzilla.novell.com/show_bug.cgi?id=653710
From: Marek Safar mailto:marek.sa...@gmail.com>>
Date: Mon, 15 Nov 2010 06:16:57 -0800
To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>"
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Generic Constraints Regression in 2.8
Hello,
Could you please fill a bug report.
Thanks
Marek
Except that Y is constrained to be of type Z and so is guaranteed to be a
reference type.
On Mon, Nov 15, 2010 at 12:30 AM, Bojan Rajkovic
mailto:severedcr...@gmail.com>> wrote:
On Nov 14, 2010, at 10:16 PM, Tom Philpot wrote:
The following code compiled with a warning on Mono 2.7 (as of 147679) but has
an error in 2.8.
namespace Application
{
public class Z {}
public class A
where Y : Z
where X : Y
{
protected void SomeOperation(Y y)
{
X x = y as X;
}
}
public class Foo { public static void Main() {} }
}
/opt/mono-2.8/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,33): error CS0413: The `as' operator cannot be used with
a non-reference type parameter `X'. Consider adding `class' or a reference type
constraint
Compilation failed: 1 error(s), 0 warnings
/opt/mono-r147679/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,27): warning CS0219: The variable `x' is assigned but
its value is never used
Compilation succeeded - 1 warning(s)
The error message here is the correct thing to do—as casts are only valid with
reference types, because they can result in null, which is invalid for a value
type. If this raised only a warning in gmcs earlier, it was a bug.
—Bojan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com<mailto: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<mailto: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<mailto: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] Generic Constraints Regression in 2.8
The following code compiled with a warning on Mono 2.7 (as of 147679) but has
an error in 2.8.
namespace Application
{
public class Z {}
public class A
where Y : Z
where X : Y
{
protected void SomeOperation(Y y)
{
X x = y as X;
}
}
public class Foo { public static void Main() {} }
}
/opt/mono-2.8/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,33): error CS0413: The `as' operator cannot be used with
a non-reference type parameter `X'. Consider adding `class' or a reference type
constraint
Compilation failed: 1 error(s), 0 warnings
/opt/mono-r147679/bin/gmcs CS0413Regression.cs
CS0413Regression.cs(12,27): warning CS0219: The variable `x' is assigned but
its value is never used
Compilation succeeded - 1 warning(s)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Differences in XmlSerializer.Serialize(stream, object)
On Mono, XmlSerializer.Serialize(object, stream) uses the default encoding for
the platform. .NET appears not to specify an encoding, as evidenced by the
output from the code below.
Due to the way it currently works on Mono, Unicode characters don't get
serialized and deserialized on Mono correctly when using the
XmlSerializer.Serialize(object, stream) constructor:
Here's the example code:
XmlSerializationText.cs
Description: XmlSerializationText.cs
Here's the output: Mono: (tested on r147679, but XmlSerializer.cs has no changes in HEAD)
http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">Biz
.NET 3.5
http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">Biz>Here's a patch that makes Mono do what .NET does in this case.Index: mcs/class/System.XML/System.Xml.Serialization/XmlSerializer.cs
===
--- mcs/class/System.XML/System.Xml.Serialization/XmlSerializer.cs
(revision 147679)
+++ mcs/class/System.XML/System.Xml.Serialization/XmlSerializer.cs
(working copy)
@@ -413,7 +413,7 @@
public void Serialize (Stream stream, object o)
{
- XmlTextWriter xmlWriter = new XmlTextWriter (stream,
System.Text.Encoding.Default);
+ XmlTextWriter xmlWriter = new XmlTextWriter (stream,
null);
xmlWriter.Formatting = Formatting.Indented;
Serialize (xmlWriter, o, null);
}
@@ -432,7 +432,7 @@
public void Serialize (Stream stream, object o,
XmlSerializerNamespaces namespaces)
{
- XmlTextWriter xmlWriter = new XmlTextWriter (stream,
System.Text.Encoding.Default);
+ XmlTextWriter xmlWriter = new XmlTextWriter (stream,
null);
xmlWriter.Formatting = Formatting.Indented;
Serialize (xmlWriter, o, namespaces);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mach kernel support for sgen
Would any of these changes make a difference on the currently shipping garbage collector? Is this something that could be back-ported? Thanks, Tom On Jun 17, 2010, at 7:54 AM, Geoff Norton wrote: > I learned recently that one of our long standing issues one mach kernels > (darwin specifically) that we chalked up to a bug in their implementation > (specifically signal coalescing) is in fact a unfounded assumption by us. > Guaranteeing 1 deliver per signal, (and infact the sem_init issue that > plagued us historically) is only guaranteed for RT signals in POSIX Realtime > Extension. As such I've started undertaking to move our runtime away from > signals for thread managment on darwin and to use mach ports instead. With > some help from Rodrigo, I got sgen playing nicely with mach ports last night > for STW. This cuts about 50% off our sys time doing GC intensive benchmarks. > > I've introduced a new set of helpers into utils for mach support and arch > specific backends for x86 and amd64. It currently is only tested on apple, > and certainly wont work anywhere else due to > mono_mach_arch_get_tls_value_from_thread being 100% apple specific. Once we > figure out what changes the runtime team would like to see I'll look at > porting it to arm. > > After getting these changes incubated, I'd like to start looking at moving > our Thread.Abort/Interrupt/Suspend semantics to mach ports, as well as sdb's > STW semantics. > > Comments? > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for environment specific location for .mono folder
On third thought, the patch below may not be that necessary for our case as the
XDG_DATA_HOME, XDG_CONFIG_HOME and MONO_SHARED_DIR can all be remapped based on
environment variables. The Registry code UnixRegistryApi.cs assumes that .mono
will live under the folder returned by g_get_home_dir() and several of the
Makefiles that deal with the Registry assume this value is $HOME, but for our
app, it's easier to just make sure we don't use the Registry than to hack Mono
to that level.
I suppose one could just add a MONO_USER_REGISTRY_PATH environment variable,
but that just increases the proliferation of environment variables that one has
to account for.
Remapping internalGetHome() to something other than the value of
g_get_home_dir() is just a fantastically bad idea.
Tom
On Jun 1, 2010, at 10:47 AM, Zoltan Varga wrote:
Hi,
The relevant code in aot-runtime.c is just some experimental code, its not
used by anyone, so you can ignore it.
Zoltan
On Tue, Jun 1, 2010 at 7:42 PM, Tom Philpot
mailto:tom.phil...@logos.com>> wrote:
After digging a little bit further, it seems there are more issues with this
patch:
First, the AOT-Runtimes assumes that .mono is under g_get_home_dir()
Secondly, System.Environment.SpecialFolder.Personal returns internalGetHome
which is g_get_home_dir()
Does it make sense to change this to a MONO_USER_HOME environment variable that
takes precedence over g_get_home_dir(), and then update references to
g_get_home_dir() to check MONO_USER_HOME first?
This would be really useful for use, and possibly others I'd expect.
Tom
On Jun 1, 2010, at 9:44 AM, Tom Philpot wrote:
> Attached is a patch that allows the user (or an embedded application) to set
> MONO_USER_CONFIG to specify a directory location for the .mono folder,
> similar to the MONO_CONFIG environment variable for mono configuration folder.
>
> We have an app which embeds Mono and we'd like to be certain that other Mono
> apps won't be tinkering with our configuration. This also allows us to make
> sure that the .mono folder can be created/updated as certain users don't have
> write access to their home folder, but do have access to sub-folders. We'd
> prefer not to have to ask for elevated permissions just to create a hidden
> config folder. Finally, this allows our application not to scatter
> configuration information throughout the file system as we can put all our
> configuration under an application specific folder.
>
> This patch is MIT/X11 licensed.
>
>
> Index: mono-config.c
> ===
> --- mono-config.c (revision 158291)
> +++ mono-config.c (working copy)
> @@ -560,7 +560,9 @@
> g_free (mono_cfg);
>
> #ifndef TARGET_WIN32
> - home = g_get_home_dir ();
> + home = g_getenv ("MONO_USER_CONFIG");
> + if (home == NULL)
> + home = g_get_home_dir ();
> user_cfg = g_strconcat (home, G_DIR_SEPARATOR_S, ".mono/config", NULL);
> mono_config_parse_file (user_cfg);
> g_free (user_cfg);
>
> Thanks,
> Tom
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com<mailto: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<mailto: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 for environment specific location for .mono folder
After digging a little bit further, it seems there are more issues with this
patch:
First, the AOT-Runtimes assumes that .mono is under g_get_home_dir()
Secondly, System.Environment.SpecialFolder.Personal returns internalGetHome
which is g_get_home_dir()
Does it make sense to change this to a MONO_USER_HOME environment variable that
takes precedence over g_get_home_dir(), and then update references to
g_get_home_dir() to check MONO_USER_HOME first?
This would be really useful for use, and possibly others I'd expect.
Tom
On Jun 1, 2010, at 9:44 AM, Tom Philpot wrote:
> Attached is a patch that allows the user (or an embedded application) to set
> MONO_USER_CONFIG to specify a directory location for the .mono folder,
> similar to the MONO_CONFIG environment variable for mono configuration folder.
>
> We have an app which embeds Mono and we'd like to be certain that other Mono
> apps won't be tinkering with our configuration. This also allows us to make
> sure that the .mono folder can be created/updated as certain users don't have
> write access to their home folder, but do have access to sub-folders. We'd
> prefer not to have to ask for elevated permissions just to create a hidden
> config folder. Finally, this allows our application not to scatter
> configuration information throughout the file system as we can put all our
> configuration under an application specific folder.
>
> This patch is MIT/X11 licensed.
>
>
> Index: mono-config.c
> ===
> --- mono-config.c (revision 158291)
> +++ mono-config.c (working copy)
> @@ -560,7 +560,9 @@
> g_free (mono_cfg);
>
> #ifndef TARGET_WIN32
> - home = g_get_home_dir ();
> + home = g_getenv ("MONO_USER_CONFIG");
> + if (home == NULL)
> + home = g_get_home_dir ();
> user_cfg = g_strconcat (home, G_DIR_SEPARATOR_S, ".mono/config", NULL);
> mono_config_parse_file (user_cfg);
> g_free (user_cfg);
>
> Thanks,
> Tom
> ___
> 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 for environment specific location for .mono folder
Attached is a patch that allows the user (or an embedded application) to set
MONO_USER_CONFIG to specify a directory location for the .mono folder, similar
to the MONO_CONFIG environment variable for mono configuration folder.
We have an app which embeds Mono and we'd like to be certain that other Mono
apps won't be tinkering with our configuration. This also allows us to make
sure that the .mono folder can be created/updated as certain users don't have
write access to their home folder, but do have access to sub-folders. We'd
prefer not to have to ask for elevated permissions just to create a hidden
config folder. Finally, this allows our application not to scatter
configuration information throughout the file system as we can put all our
configuration under an application specific folder.
This patch is MIT/X11 licensed.
Index: mono-config.c
===
--- mono-config.c (revision 158291)
+++ mono-config.c (working copy)
@@ -560,7 +560,9 @@
g_free (mono_cfg);
#ifndef TARGET_WIN32
- home = g_get_home_dir ();
+ home = g_getenv ("MONO_USER_CONFIG");
+ if (home == NULL)
+ home = g_get_home_dir ();
user_cfg = g_strconcat (home, G_DIR_SEPARATOR_S, ".mono/config", NULL);
mono_config_parse_file (user_cfg);
g_free (user_cfg);
Thanks,
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UriBuilder bug in Bugzilla (with Patch)
We've encountered problems with this bug: https://bugzilla.novell.com/show_bug.cgi?id=532291 It's seems that there is a patch and regression test cases for Mono which have been languishing in Bugzilla for a while. Would someone be so kind as to review and commit the patch? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Regex.Match(string, int, int) behaves differently than Microsoft's implementation
So we've reported this bug here:
https://bugzilla.novell.com/show_bug.cgi?id=474154
Text of the bug report is as follows:
Certain regular expressions will behave differently on Mono when calling
Regex.Match(string, int, int). In particular the expression
new Regex("^quick$").Match("The quick brown fox jumps over the lazy dog.", 4,
5).Success
evaluates to true in Microsoft's implementation, but false in Mono. It appears
that in Microsoft's implementation, the results of the method are comparable to
calling string.Substring() on the string being passed in, except that indexes
are still reported in terms of the original string.
As a side note, the expression
new Regex("^quick").Match("The quick brown fox jumps over the lazy dog.",
4).Success
evaluates to false both in Microsoft's implementation and in Mono. Any fix to
the former should not break the latter.
Before I went digging into the bug, I thought I'd ask if any of the devs had a
quick fix.
Thanks,
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Runtime or JIT bug in Mono trunk? (Bugzilla 562150)
Mono devs, We're more or less tracking Mono trunk on a regular basis, but it seems there's been a regression introduced in 2.7 in the JIT that causes a crash under certain circumstances that makes trunk unusable for us because the runtime aborts when running our unit tests. I think what we're seeing is a manifestation of bug 562150 (https://bugzilla.novell.com/show_bug.cgi?id=562150). I've attached a sanitized version of our test case to be bug report in Bugzilla to help reproduce the crash. The crash only seems to appear on 2.7 and not on 2.6.1. The bug wasn't present in r147679, but by the time we updated to 149976 it was, just to give you some context for where the problem might have been introduced. Any chance someone could take a look at this and see if it's an easy fix? We'd really love to keep tracking trunk, and not keep backporting patches to an old 2.7 revision. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libmono.0.dylib versus libmono-2.0.dylib
I noticed that in today's SVN build of mono, libmono is now libmono-2.0.dylib instead of libmono.0.dylib as in previous versions? Was there a reason for change? I ask because we can no longer use "-lmono" but now have to use "-lmono-2" if we use a Mono svn build from today on. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for DateTime.TryParseExact handling of null input string
.NET 3.5 does not throw a null reference exception on DateTime.TryParseExact if
the first parameter is null.
Attached is a test case and a fix for DateTime.cs
Index: System/DateTime.cs
===
--- System/DateTime.cs (revision 152377)
+++ System/DateTime.cs (working copy)
@@ -1164,6 +1164,9 @@
result = new DateTime (0);
if (format == null)
return false;
+
+ if (s == null)
+ return false;
if ((style & DateTimeStyles.AllowLeadingWhite) != 0) {
format = format.TrimStart (null);
Index: Test/System/DateTimeTest.cs
===
--- Test/System/DateTimeTest.cs (revision 152377)
+++ Test/System/DateTimeTest.cs (working copy)
@@ -2417,6 +2417,15 @@
// bug #444103.
DateTime.ParseExact ("12:00:00", "HH:mm:ss.FFF",
null);
}
+
+ [Test]
+ public void TryParseExact_NullString ()
+ {
+ DateTime dt;
+ DateTime.TryParseExact(null,
"'-'MM'-'dd'T'HH':'mm':'ss'Z'", CultureInfo.InvariantCulture,
+
DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal, out dt);
+ Assert.AreEqual(default(DateTime), dt);
+ }
#endif
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono-semaphore.c broken on MacOSX in SVN
Mono-semaphore.c won't compile on Mac. I *think* the patch below will fix it in both cases, but my macros are pretty rusty. Basically, semaphore_timedwait doesn't take a mach_timespec_t* where as sem_timedwait does take a struct timespec * ws1048-snow:mono tom.philpot$ svn diff mono/utils/mono-semaphore.c Index: mono/utils/mono-semaphore.c === --- mono/utils/mono-semaphore.c (revision 152312) +++ mono/utils/mono-semaphore.c (working copy) @@ -17,7 +17,7 @@ #define WAIT_BLOCK(a,b) semaphore_timedwait (a, b) # else #define TIMESPEC struct timespec -#define WAIT_BLOCK(a,b) sem_timedwait (a, b) +#define WAIT_BLOCK(a,b) sem_timedwait (a, &##b) # endif gboolean @@ -32,7 +32,7 @@ tv.tv_sec = timeout_ms / 1000; tv.tv_nsec = (timeout_ms % 1000) * 100; - return (!WAIT_BLOCK (sem, &tv)); + return (!WAIT_BLOCK (sem, tv)); } #else ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
There are several patches for Mac that I'd like to make sure are in the 2.6.x
point release:
- Fix for CookieContainer.cs
CookieContainer.cs r149976
CookieContainerTests.cs r149976
- Fix for BufferedStream Read/Write
BufferedStream.cs r149799
The following patch contains several other fixes which are already on 2.7 but
which may or may not be on 2.6 branch
Index: mcs/class/corlib/System/DateTimeOffset.cs
===
--- mcs/class/corlib/System/DateTimeOffset.cs (revision 147113)
+++ mcs/class/corlib/System/DateTimeOffset.cs (working copy)
@@ -47,7 +47,7 @@
public DateTimeOffset (DateTime dateTime)
{
- dt = dateTime;
+ dt = DateTime.SpecifyKind(dateTime,
DateTimeKind.Unspecified);
if (dateTime.Kind == DateTimeKind.Utc)
utc_offset = TimeSpan.Zero;
Index:
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs
===
---
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs
(revision 147113)
+++
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10ItemFormatter.cs
(working copy)
@@ -499,6 +499,7 @@
writer.WriteEndElement ();
}
+ WriteElementExtensions (writer, Item, Version);
if (writeRoot)
writer.WriteEndElement ();
}
Index:
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs
===
---
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs
(revision 147113)
+++
mcs/class/System.ServiceModel.Web/System.ServiceModel.Syndication/Atom10FeedFormatter.cs
(working copy)
@@ -486,6 +486,7 @@
WriteItems (writer, Feed.Items, Feed.BaseUri);
+ WriteElementExtensions (writer, Feed, Version);
if (writeRoot)
writer.WriteEndElement ();
}
Index: mono/mono/io-layer/processes.c
===
--- mono/mono/io-layer/processes.c (revision 147113)
+++ mono/mono/io-layer/processes.c (working copy)
@@ -1489,8 +1489,73 @@
}
#endif /* UNUSED_CODE */
+#ifdef PLATFORM_MACOSX
+#include
+#include
+
gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed)
{
+ guint32 count, fit, i, j;
+ gint32 err;
+ gboolean done;
+ struct kinfo_proc *result;
+ size_t proclength;
+ static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
+
+ mono_once (&process_current_once, process_set_current);
+
+ result = NULL;
+ done = FALSE;
+
+ do {
+ proclength = 0;
+ err = sysctl ((int *)name, (sizeof(name) / sizeof(*name)) - 1,
NULL, &proclength, NULL, 0);
+ if (err == -1) {
+ err = errno;
+ }
+
+ if (err == 0) {
+ result = g_malloc (proclength);
+ if (result == NULL) {
+ err = ENOMEM;
+ }
+ }
+
+ if (err == 0) {
+ err = sysctl ((int *) name, (sizeof(name) /
sizeof(*name)) - 1, result, &proclength, NULL, 0);
+ if (err == -1) {
+ err = errno;
+ }
+ if (err == 0) {
+ done = TRUE;
+ } else if (err == ENOMEM) {
+ free(result);
+ result = NULL;
+ err = 0;
+ }
+ }
+ } while (err == 0 && !done);
+
+ if (err != 0 && result != NULL) {
+ free (result);
+ result = NULL;
+ return(FALSE);
+ }
+
+ count = proclength / sizeof(struct kinfo_proc);
+ fit = len / sizeof(guint32);
+ for (i = 0, j = 0; j< fit && i < count; i++) {
+ pids [j++] = result [i].kp_proc.p_pid;
+ }
+ free (result);
+ result = NULL;
+ *needed = j * sizeof(guint32);
+
+ return(TRUE);
+}
+#else
+gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed)
+{
GArray *processes = g_array_new (FALSE, FALSE, sizeof(pid_t));
guint32 fit, i, j;
DIR *dir;
@@ -1528,6 +1593,7 @@
return(TRUE);
}
+#endif
static gboolean process_open_compare (gpo
Re: [Mono-dev] Mac Boehm CG question
I reran the revised test case Matteo provided here: https://bugzilla.novell.com/show_bug.cgi?id=402833 Here are the results with NO_PTHREAD_TRYLOCK defined (i.e. before) ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe One Thread (method1) time=00:00:00.6318450 One Thread (method2) time=00:00:00.6434430 Two Thread time=00:00:03.7889390 ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe One Thread (method1) time=00:00:00.6311450 One Thread (method2) time=00:00:00.6421380 Two Thread time=00:00:03.7577420 Here are the results without NO_PTHREAD_TRYLOCK defined (i.e. after) ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe One Thread (method1) time=00:00:00.6295460 One Thread (method2) time=00:00:00.6389300 Two Thread time=00:00:00.2641640 ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe One Thread (method1) time=00:00:00.6306050 One Thread (method2) time=00:00:00.6370260 Two Thread time=00:00:00.2639220 This was on a Mac Pro 2.66 Ghz on 10.6. I haven't run them on 10.5. Tom On Jan 25, 2010, at 5:16 PM, matteo tesser wrote: > Hi, > about an year ago I posted the following bug > https://bugzilla.novell.com/show_bug.cgi?id=402833 > because we realized that the performance problem in our multi-thread > app was related to memory management: > > By removing the #define line as you proposed, the performance problem > disappear and bug 402833 seems resolved. > At the moment I made also some preliminary tests on our multi-thread > app and performances improve considerably. > > Matteo > > > On Mon, Jan 25, 2010 at 10:59 PM, Tom Philpot wrote: >> Rodrigo, >> Thanks for the input. Any of the other Mono/MacOS X folks have an opinion on >> this change? I've been running our heavily multi-threaded app which embeds >> Mono and haven't seen any issues. We're going to start removing this #define >> on our build machine and our dev's Mono installs and see if we can detect >> any issues since the speed up is so significant in certain cases in our app. >> Tom >> >> On Jan 22, 2010, at 2:08 PM, Rodrigo Kumpera wrote: >> >> pthread mutexes on OSX are ridiculously slow. So no matter what you do, GC >> performance will be significantly worse than on linux. >> But we should check if this change is ok if it does give a nice boost. >> >> >> >> On Fri, Jan 22, 2010 at 8:05 PM, Tom Philpot wrote: >>> >>> While investigating some performance problems in our application which >>> uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I >>> noticed that several operations spent an extreme amount of time in GC_lock. >>> That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. >>> I've commented out that #define it on my local Mono build and things seem >>> MUCH faster. In fact I'm now able to do real work on more than 2 threads >>> without a ton of overhead. >>> >>> The question is now, does this check still need to be there for later >>> versions of Mac OS X? The original commit was back in August 2003, which was >>> probably around the timeframe of 10.2 and 10.3 and definitely before the >>> Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that >>> #define. >>> >>> >>> ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h >>> Index: libgc/include/private/gcconfig.h >>> === >>> --- libgc/include/private/gcconfig.h(revision 150077) >>> +++ libgc/include/private/gcconfig.h(working copy) >>> @@ -329,7 +329,7 @@ >>> #define GETPAGESIZE() getpagesize() >>> /* There seems to be some issues with trylock hanging on darwin. >>> This >>> should be looked into some more */ >>> -# define NO_PTHREAD_TRYLOCK >>> +//# define NO_PTHREAD_TRYLOCK >>> # elif defined(__arm__) >>> #define ARM >>> #define mach_type_known >>> >>> ___ >>> 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] Mac Boehm CG question
Rodrigo, Thanks for the input. Any of the other Mono/MacOS X folks have an opinion on this change? I've been running our heavily multi-threaded app which embeds Mono and haven't seen any issues. We're going to start removing this #define on our build machine and our dev's Mono installs and see if we can detect any issues since the speed up is so significant in certain cases in our app. Tom On Jan 22, 2010, at 2:08 PM, Rodrigo Kumpera wrote: pthread mutexes on OSX are ridiculously slow. So no matter what you do, GC performance will be significantly worse than on linux. But we should check if this change is ok if it does give a nice boost. On Fri, Jan 22, 2010 at 8:05 PM, Tom Philpot mailto:tom.phil...@logos.com>> wrote: While investigating some performance problems in our application which uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that several operations spent an extreme amount of time in GC_lock. That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. I've commented out that #define it on my local Mono build and things seem MUCH faster. In fact I'm now able to do real work on more than 2 threads without a ton of overhead. The question is now, does this check still need to be there for later versions of Mac OS X? The original commit was back in August 2003, which was probably around the timeframe of 10.2 and 10.3 and definitely before the Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that #define. ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h Index: libgc/include/private/gcconfig.h === --- libgc/include/private/gcconfig.h(revision 150077) +++ libgc/include/private/gcconfig.h(working copy) @@ -329,7 +329,7 @@ #define GETPAGESIZE() getpagesize() /* There seems to be some issues with trylock hanging on darwin. This should be looked into some more */ -# define NO_PTHREAD_TRYLOCK +//# define NO_PTHREAD_TRYLOCK # elif defined(__arm__) #define ARM #define mach_type_known ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com<mailto: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] Mac Boehm CG question
While investigating some performance problems in our application which uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that several operations spent an extreme amount of time in GC_lock. That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. I've commented out that #define it on my local Mono build and things seem MUCH faster. In fact I'm now able to do real work on more than 2 threads without a ton of overhead. The question is now, does this check still need to be there for later versions of Mac OS X? The original commit was back in August 2003, which was probably around the timeframe of 10.2 and 10.3 and definitely before the Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that #define. ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h Index: libgc/include/private/gcconfig.h === --- libgc/include/private/gcconfig.h(revision 150077) +++ libgc/include/private/gcconfig.h(working copy) @@ -329,7 +329,7 @@ #define GETPAGESIZE() getpagesize() /* There seems to be some issues with trylock hanging on darwin. This should be looked into some more */ -# define NO_PTHREAD_TRYLOCK +//# define NO_PTHREAD_TRYLOCK # elif defined(__arm__) #define ARM #define mach_type_known ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for CookieContainer.SetCookies
On Jan 20, 2010, at 1:58 PM, Sebastien Pouliot wrote:
why not simply
c.HttpOnly = cookie.HttpOnly;
c.Secure = cookie.Secure;
?
if there's a problem with this simpler code then it does not get caught
by your new unit tests.
I had thought I saw code like the following in Cookie.cs (for Secure and
HttpOnly) at one point.
public bool Secure
{
get { return secure; }
set { secure = true; }
}
Je fumais la moquette.
I suspect the "expires" case is the buggy one wrt your unit test
(previous email).
Sebastien
The expires test case worked perfectly if you're on the Pacific Time Zone ;).
It should be fixed in this patch.
I believe I've followed the coding conventions, but I'm not quite sure about
the long Regex's in CookieContainer.cs.
Index: System.Net/CookieContainer.cs
===
--- System.Net/CookieContainer.cs (revision 149933)
+++ System.Net/CookieContainer.cs (working copy)
@@ -36,6 +36,7 @@
using System.Globalization;
using System.Runtime.Serialization;
using System.Text;
+using System.Text.RegularExpressions;
namespace System.Net
{
@@ -146,7 +147,16 @@
if (cookie.Value.Length > maxCookieSize)
throw new CookieException ("value is larger
than MaxCookieSize.");
- AddCookie (cookie);
+ // .NET's Add (Cookie) is fundamentally broken and does
not copy properties
+ // like Secure, HttpOnly and Expires so we clone the
parts that .NET
+ // does keep before calling AddCookie
+ Cookie c = new Cookie (cookie.Name, cookie.Value);
+ c.Path = (cookie.Path.Length == 0) ? "/" : cookie.Path;
+ c.Domain = cookie.Domain;
+ c.ExactDomain = cookie.ExactDomain;
+ c.Version = cookie.Version;
+
+ AddCookie (c);
}
void AddCookie (Cookie cookie)
@@ -169,6 +179,12 @@
c.Domain = cookie.Domain;
c.ExactDomain = cookie.ExactDomain;
c.Version = cookie.Version;
+ c.Expires = cookie.Expires;
+ c.CommentUri = cookie.CommentUri;
+ c.Comment = cookie.Comment;
+ c.Discard = cookie.Discard;
+ c.HttpOnly = cookie.HttpOnly;
+ c.Secure = cookie.Secure;
cookies.Add (c);
CheckExpiration ();
@@ -373,10 +389,25 @@
return;
// Cookies must be separated by ',' (like documented on
MSDN)
+ // but expires uses DAY, DD-MMM- HH:MM:SS GMT, so
simple ',' search is wrong.
+ // See
http://msdn.microsoft.com/en-us/library/aa384321%28VS.85%29.aspx
string [] jar = cookieHeader.Split (',');
- foreach (string cookie in jar) {
+ string tmpCookie;
+ for (int i = 0; i < jar.Length; i++) {
+ tmpCookie = jar [i];
+
+ if (jar.Length > i + 1
+ && Regex.IsMatch (jar[i],
+
@".*expires\s*=\s*(Mon|Tue|Wed|Thu|Fri|Sat|Sun)",
+ RegexOptions.IgnoreCase)
+ && Regex.IsMatch (jar[i+1],
+
@"\s\d{2}-(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-\d{4}
\d{2}:\d{2}:\d{2} GMT",
+ RegexOptions.IgnoreCase)) {
+ tmpCookie = new StringBuilder
(tmpCookie).Append (",").Append (jar [++i]).ToString ();
+ }
+
try {
- Cookie c = Parse (cookie);
+ Cookie c = Parse (tmpCookie);
// add default values from URI if
missing from the string
if (c.Path.Length == 0) {
@@ -392,7 +423,7 @@
c.ExactDomain = true;
}
- Add (c);
+ AddCookie (c);
}
catch (Exception e) {
string msg = String.Format ("Could not
parse cookies for '{0}'.", uri);
@@ -430,6 +461,18 @@
c.ExactDomain = false;
}
Re: [Mono-dev] Patch for CookieContainer.SetCookies
Oh, and these patches are MIT/X11 licensed. On Jan 18, 2010, at 3:31 PM, Tom Philpot wrote: > The current implementation of CookieContainer.SetCookies does not handle the > case where a cookie contains an "expires=..." attribute. > > As documented on MSDN here: > http://msdn.microsoft.com/en-us/library/aa384321%28VS.85%29.aspx the > "Set-Cookie:" header expires attribute uses the following format: DAY, > DD-MMM- HH:MM:SS GMT > > The current version of SetCookies simply does a split on ',' in the header > which totally causes the CookieContainer to choke when the expires attribute > is set as MS recommends. > > Also, the Add (Cookie) method of CookieContainer does not clone all the > properties of the incoming cookie before adding it to the collection. Using > SetCookies(Uri, string) should clone all the properties, so that is fixes as > well in the patch and a test is added in the test cases. > > I believe this makes the behavior of CookieContainer more "bug-compatible" > with .NET. > > Please review the patch and the test cases. > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for CookieContainer.SetCookies
The current implementation of CookieContainer.SetCookies does not handle the
case where a cookie contains an "expires=..." attribute.
As documented on MSDN here:
http://msdn.microsoft.com/en-us/library/aa384321%28VS.85%29.aspx the
"Set-Cookie:" header expires attribute uses the following format: DAY,
DD-MMM- HH:MM:SS GMT
The current version of SetCookies simply does a split on ',' in the header
which totally causes the CookieContainer to choke when the expires attribute is
set as MS recommends.
Also, the Add (Cookie) method of CookieContainer does not clone all the
properties of the incoming cookie before adding it to the collection. Using
SetCookies(Uri, string) should clone all the properties, so that is fixes as
well in the patch and a test is added in the test cases.
I believe this makes the behavior of CookieContainer more "bug-compatible" with
.NET.
Please review the patch and the test cases.
Index: mcs/class/System/System.Net/CookieContainer.cs
===
--- mcs/class/System/System.Net/CookieContainer.cs (revision 149764)
+++ mcs/class/System/System.Net/CookieContainer.cs (working copy)
@@ -36,6 +36,7 @@
using System.Globalization;
using System.Runtime.Serialization;
using System.Text;
+using System.Text.RegularExpressions;
namespace System.Net
{
@@ -53,7 +54,7 @@
int perDomainCapacity = DefaultPerDomainCookieLimit;
int maxCookieSize = DefaultCookieLengthLimit;
CookieCollection cookies;
-
+
// ctors
public CookieContainer ()
{
@@ -146,7 +147,16 @@
if (cookie.Value.Length > maxCookieSize)
throw new CookieException ("value is larger
than MaxCookieSize.");
- AddCookie (cookie);
+ // .NET's Add (Cookie) is fundamentally broken and does
not copy properties
+ // like Secure, HttpOnly and Expires so we clone the
parts that .NET
+ // does keep before calling AddCookie
+ Cookie c = new Cookie (cookie.Name, cookie.Value);
+ c.Path = (cookie.Path.Length == 0) ? "/" : cookie.Path;
+ c.Domain = cookie.Domain;
+ c.ExactDomain = cookie.ExactDomain;
+ c.Version = cookie.Version;
+
+ AddCookie (c);
}
void AddCookie (Cookie cookie)
@@ -169,6 +179,16 @@
c.Domain = cookie.Domain;
c.ExactDomain = cookie.ExactDomain;
c.Version = cookie.Version;
+ c.Expires = cookie.Expires;
+ c.CommentUri = cookie.CommentUri;
+ c.Comment = cookie.Comment;
+ c.Discard = c.Discard;
+ if (cookie.HttpOnly) {
+ c.HttpOnly = true;
+ }
+ if (cookie.Secure) {
+ c.Secure = true;
+ }
cookies.Add (c);
CheckExpiration ();
@@ -373,10 +393,21 @@
return;
// Cookies must be separated by ',' (like documented on
MSDN)
- string [] jar = cookieHeader.Split (',');
- foreach (string cookie in jar) {
+ // but expires uses DAY, DD-MMM- HH:MM:SS GMT, so
simple ',' search is wrong.
+ // See
http://msdn.microsoft.com/en-us/library/aa384321%28VS.85%29.aspx
+ string[] jar = cookieHeader.Split(',');
+ string tmpCookie;
+ for (int i = 0; i < jar.Length; i++) {
+ tmpCookie = jar[i];
+
+ if (jar.Length > i + 1
+ && Regex.IsMatch (jar[i],
@".*expires\s*=\s*(Mon|Tue|Wed|Thu|Fri|Sat|Sun)", RegexOptions.IgnoreCase)
+ && Regex.IsMatch (jar[i+1],
@"\s\d{2}-(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-\d{4}
\d{2}:\d{2}:\d{2} GMT", RegexOptions.IgnoreCase)) {
+ tmpCookie = new
StringBuilder(tmpCookie).Append(",").Append(jar[++i]).ToString();
+ }
+
try {
- Cookie c = Parse (cookie);
+ Cookie c = Parse (tmpCookie);
// add default values from URI if
missing from the string
if (c.Path.Length == 0) {
@@ -392,7 +423,7 @@
[Mono-dev] Error running embedded Mono runtime
When running with the Mono r149505 embedded in our application, we get the following error on startup: ERROR:metadata.c:2183:get_image_set: assertion failed: (nimages > 0) Program received signal: “SIGABRT”. The first 20 frames of the GDB backtrace from mono_backtrace() are: #0 0x934b9732 in __kill () #1 0x934b9724 in kill$UNIX2003 () #2 0x9354c98d in raise () #3 0x93562a44 in abort () #4 0x0435c9a2 in g_assertion_message () #5 0x0435d018 in g_assertion_message_expr () #6 0x02897bc5 in get_image_set () #7 0x02899091 in mono_metadata_get_generic_inst () #8 0x028549a9 in init_generic_context_from_args () #9 0x02854ec6 in ves_icall_System_Reflection_Module_ResolveFieldToken () #10 0x18eaaab4 in (wrapper managed-to-native) System.Reflection.Module:ResolveFieldToken (intptr,int,intptr[],intptr[],System.Reflection.ResolveTokenError&) + 0x34 (0x18eaaa80 0x18eaaadb) [0x11890e58 - Bootstrap.exe] #11 0x18eaa8fb in System.Reflection.Module:ResolveField (int,System.Type[],System.Type[]) + 0x53 (0x18eaa8a8 0x18eaa973) [0x11890e58 - Bootstrap.exe] #12 0x18eaa192 in .: () + 0x1c2 (0x18ea9fd0 0x18eaa1b1) [0x11890e58 - Bootstrap.exe] #13 0x18ea936f in .: (System.Type) + 0x257 (0x18ea9118 0x18ea9470) [0x11890e58 - Bootstrap.exe] #14 0x18ea90fa in .:.ctor (System.Type) + 0x3a (0x18ea90c0 0x18ea90ff) [0x11890e58 - Bootstrap.exe] #15 0x18ea5bf8 in .:.ctor (System.Type) + 0x50 (0x18ea5ba8 0x18ea5c06) [0x11890e58 - Bootstrap.exe] #16 0x18ea5b8d in .b: (System.Type) + 0x25 (0x18ea5b68 0x18ea5b95) [0x11890e58 - Bootstrap.exe] #17 0x18ea53e7 in .: (object) + 0x17f (0x18ea5268 0x18ea5421) [0x11890e58 - Bootstrap.exe] #18 0x18ea5221 in .b: (object,int&) + 0x21 (0x18ea5200 0x18ea524a) [0x11890e58 - Bootstrap.exe] #19 0x18ea4ebc in Mindscape.LightSpeed.Entity:GetInferredFieldName (int&) + 0x24 (0x18ea4e98 0x18ea4ffa) [0x11890e58 - Bootstrap.exe] #20 0x18ea4e64 in Mindscape.LightSpeed.Entity:Get (int&) + 0x14 (0x18ea4e50 0x18ea4e7b) [0x11890e58 - Bootstrap.exe] ... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re gression in gmcs (svn-head)
This is evidently fixed in r149505. It might have been earlier, but at least it's working again. On Jan 13, 2010, at 4:29 AM, Marek Safar wrote: > Hi, >> For the record, someone else noticed this: >> http://old.nabble.com/Possible-regression-in-gmcs-with-private-const-member-variables.-ts27116843ef1367.html >> > and I am working on the fix. > > Marek > >> >> Leszek Ciesielski wrote: >> >>> Hi, >>> >>> between 07.01.2010 and 11.01.2010 gmcs built from svn head has >>> regressed and is now reporting >>> >>> error CS0169: The private constant >>> `Core.Configuration.ModifyConfig.filesSearchPattern' is never used >>> >>> on code >>> >>> private const string filesSearchPattern = "*.ModifyConfig"; //this >>> constant is referenced in the same class that declares it >>> ___ >>> 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] BufferedStream.ReadByte and WriteByte are extremely inefficient
Kornel, Alan
Did these patches check out enough to commit to SVN?
Thanks,
Tom
On Jan 11, 2010, at 4:18 PM, Tom Philpot wrote:
> Ah, yes. I forgot to check that m_buffer.Length == 0 is explicitly disallowed
> in the constructor, so yes, eliminating an extra if will speed things up.
>
> Here's another patch which is, again, MIT/X11 licensed.
>
>
> On Jan 11, 2010, at 3:58 PM, Kornél Pál wrote:
>
> Hi,
>
> This actually means 1 == m_buffer.Length that effectively means no
> buffering. As such there is no use to optimize (special case) for 1 ==
> m_buffer.Length.
>
> The code will continue to function properly in this special case and
> will be faster in more likely (truly buffered) use cases by simply
> eliminating the "if" by using the "else" case for the 1 ==
> m_buffer.Length case as well.
>
> Kornél
>
> Alan McGovern wrote:
> Actually, ignore the part about the 1 >= m_buffer.Length. On second
> reading that's fine ;)
>
> Alan.
>
> On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern <mailto:alan.mcgov...@gmail.com>> wrote:
>
> Hey,
>
> This patch does three things:
>
> 1) Optimises away some allocations - good
> 2) Added extra checks which throw exceptions - without providing
> testcases - bad
> 3) A fair few whitespace changes - bad
>
> Would you be able to submit two patches instead? The first should do
> the optimisation, the second should add the test+exception for
> CanRead and CanWrite as well as adding some nunit test cases which
> show that this is required.
>
> Also:
>
> + if (1 >= m_buffer.Length) {
> + return m_stream.ReadByte ();
>
> That should really be: if m_buffer.Length == 0 as the case where the
> Length is >= 0 is already handled. It makes things easier to understand.
>
> Thanks,
> Alan.
>
> On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot<mailto:tom.phil...@logos.com>> wrote:
>
> Sorry, for double posting this patch. Snow Leopard's Mail.app w/
> Exchange support turned my "This is contributed under the
> MIT/X11 license" into an attachment.
>
> For the record, the code in this patch is contributed under the
> MIT/X11 license
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> <mailto: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
[Mono-dev] Mono SVN trunk assert failure in class.c:4021 while building Mono
Trying to build mono/ and mcs/ from SVN r149419 on Mac OS X 10.6 I get an assertion failure in class.c:4021 at which point Mono consumes about 75% of one core and must be kill -9'd Compilation succeeded - 31 warning(s) Assembly ../../class/lib/net_2_0/System.Core.dll signed. Creating ../../build/deps/net_2_0_Mono.Security.dll.makefrag ... Creating ../../build/deps/Mono.Security_test_net_2_0.dll.response ... Creating ../../build/deps/Mono.Security_test_net_2_0.dll.makefrag ... make all-local MCS [net_2_0] Mono.Security.dll ** ERROR:class.c:4021:initialize_object_slots: assertion failed: (finalize_slot > 0) Note that r149400 doesn't have this issue. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
Ah, yes. I forgot to check that m_buffer.Length == 0 is explicitly disallowed
in the constructor, so yes, eliminating an extra if will speed things up.
Here's another patch which is, again, MIT/X11 licensed.
On Jan 11, 2010, at 3:58 PM, Kornél Pál wrote:
Hi,
This actually means 1 == m_buffer.Length that effectively means no
buffering. As such there is no use to optimize (special case) for 1 ==
m_buffer.Length.
The code will continue to function properly in this special case and
will be faster in more likely (truly buffered) use cases by simply
eliminating the "if" by using the "else" case for the 1 ==
m_buffer.Length case as well.
Kornél
Alan McGovern wrote:
Actually, ignore the part about the 1 >= m_buffer.Length. On second
reading that's fine ;)
Alan.
On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern mailto:alan.mcgov...@gmail.com>> wrote:
Hey,
This patch does three things:
1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing
testcases - bad
3) A fair few whitespace changes - bad
Would you be able to submit two patches instead? The first should do
the optimisation, the second should add the test+exception for
CanRead and CanWrite as well as adding some nunit test cases which
show that this is required.
Also:
+ if (1 >= m_buffer.Length) {
+ return m_stream.ReadByte ();
That should really be: if m_buffer.Length == 0 as the case where the
Length is >= 0 is already handled. It makes things easier to understand.
Thanks,
Alan.
On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot mailto:tom.phil...@logos.com>> wrote:
Sorry, for double posting this patch. Snow Leopard's Mail.app w/
Exchange support turned my "This is contributed under the
MIT/X11 license" into an attachment.
For the record, the code in this patch is contributed under the
MIT/X11 license
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
<mailto: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
Index: mcs/class/corlib/System.IO/BufferedStream.cs
===
--- mcs/class/corlib/System.IO/BufferedStream.cs(revision 147679)
+++ mcs/class/corlib/System.IO/BufferedStream.cs(working copy)
@@ -169,22 +169,54 @@
{
CheckObjectDisposedException ();
- byte[] b = new byte[1];
+ if (!m_stream.CanRead) {
+ throw new NotSupportedException (
+ Locale.GetText ("Cannot read from
stream"));
+ }
- if (Read(b, 0, 1) == 1) {
- return b[0];
- } else {
- return -1;
+ if (!m_buffer_reading) {
+ Flush ();
+ m_buffer_reading = true;
}
+
+ if (1 <= m_buffer_read_ahead - m_buffer_pos) {
+ return m_buffer [m_buffer_pos++];
+ }
+ else
+ {
+ if (m_buffer_pos >= m_buffer_read_ahead) {
+ m_buffer_pos = 0;
+ m_buffer_read_ahead = 0;
+ }
+
+ m_buffer_read_ahead = m_stream.Read (m_buffer,
0, m_buffer.Length);
+ if (1 <= m_buffer_read_ahead) {
+ return m_buffer [m_buffer_pos++];
+ } else {
+ return -1;
+ }
+ }
}
public override void WriteByte (byte value)
{
CheckObjectDisposedException ();
- byte[] b = new byte[1];
+ if (!m_stream.CanWrite) {
+ throw new NotSupportedException (
+ Locale.GetText ("Cannot write to
stream"));
+ }
- b[0] = value;
- Write(b, 0, 1);
+ if (m_buffer_reading) {
+ Flush ();
+
Re: [Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
45,6 +354,15 @@
}
[Test]
+ [ExpectedException(typeof(NotSupportedException))]
+ public void WriteByte_CantWrite ()
+ {
+ ReadOnlyStream ro = new ReadOnlyStream ();
+ BufferedStream stream = new BufferedStream (ro);
+ stream.WriteByte (0);
+ }
+
+ [Test]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void Write_OffsetNegative ()
{
On Jan 11, 2010, at 3:26 PM, Alan McGovern wrote:Actually, ignore the part about the 1 >= m_buffer.Length. On second reading that's fine ;)Alan.On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern <alan.mcgov...@gmail.com> wrote:
Hey,This patch does three things:1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing testcases - bad3) A fair few whitespace changes - bad
Would you be able to submit two patches instead? The first should do the optimisation, the second should add the test+exception for CanRead and CanWrite as well as adding some nunit test cases which show that this is required.
Also:+if (1 >= m_buffer.Length) {+ return m_stream.ReadByte ();That should really be: if m_buffer.Length == 0 as the case where the Length is >= 0 is already handled. It makes things easier to understand.
Thanks,Alan.On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot <tom.phil...@logos.com> wrote:
Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange support turned my "This is contributed under the MIT/X11 license" into an attachment.
For the record, the code in this patch is contributed under the MIT/X11 license
___
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] BufferedStream.ReadByte and WriteByte are extremely inefficient
Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
support turned my "This is contributed under the MIT/X11 license" into an
attachment.
For the record, the code in this patch is contributed under the MIT/X11 license
Index: mcs/class/corlib/System.IO/BufferedStream.cs
===
--- mcs/class/corlib/System.IO/BufferedStream.cs(revision 147679)
+++ mcs/class/corlib/System.IO/BufferedStream.cs(working copy)
@@ -88,7 +88,7 @@
return m_stream.Length;
}
}
-
+
public override long Position {
get {
CheckObjectDisposedException ();
@@ -159,7 +159,7 @@
if ((m_stream == null) || (!m_stream.CanRead &&
!m_stream.CanWrite))
throw new IOException ("the stream is not
open");
-
+
m_stream.SetLength(value);
if (Position > value)
Position = value;
@@ -168,23 +168,59 @@
public override int ReadByte ()
{
CheckObjectDisposedException ();
-
- byte[] b = new byte[1];
+ if (!m_stream.CanRead) {
+ throw new NotSupportedException (
+ Locale.GetText ("Cannot read from
stream"));
+ }
- if (Read(b, 0, 1) == 1) {
- return b[0];
- } else {
- return -1;
+ if (!m_buffer_reading) {
+ Flush ();
+ m_buffer_reading = true;
}
+
+ if (1 <= m_buffer_read_ahead - m_buffer_pos) {
+ return m_buffer [m_buffer_pos++];
+ }
+ else
+ {
+ if (1 >= m_buffer.Length) {
+ return m_stream.ReadByte ();
+ } else {
+
+ if (m_buffer_pos >=
m_buffer_read_ahead) {
+ m_buffer_pos = 0;
+ m_buffer_read_ahead = 0;
+ }
+
+ m_buffer_read_ahead = m_stream.Read
(m_buffer, 0, m_buffer.Length);
+ if (1 <= m_buffer_read_ahead) {
+ return m_buffer
[m_buffer_pos++];
+ } else {
+ return -1;
+ }
+ }
+ }
}
public override void WriteByte (byte value)
{
CheckObjectDisposedException ();
- byte[] b = new byte[1];
+ if (!m_stream.CanWrite) {
+ throw new NotSupportedException (
+ Locale.GetText ("Cannot write to
stream"));
+ }
- b[0] = value;
- Write(b, 0, 1);
+ if (m_buffer_reading) {
+ Flush ();
+ m_buffer_reading = false;
+ }
+ else
+ // reordered to avoid possible integer overflow
+ if (m_buffer_pos >= m_buffer.Length - 1) {
+ Flush ();
+ }
+
+ m_buffer [m_buffer_pos++] = value;
}
public override int Read ([In,Out] byte[] array, int offset,
int count)
@@ -229,10 +265,10 @@
count -= ret;
if (count >= m_buffer.Length) {
- ret += m_stream.Read(array, offset, count);
+ ret += m_stream.Read (array, offset, count);
} else {
- m_buffer_read_ahead = m_stream.Read(m_buffer,
0, m_buffer.Length);
-
+ m_buffer_read_ahead = m_stream.Read (m_buffer,
0, m_buffer.Length);
+
if (count < m_buffer_read_ahead) {
Buffer.BlockCopyInternal (m_buffer, 0,
array, offset, count);
Re: [Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
> BufferedStream should buffer the data in both directions that is > actually implemented for Read and Write methods but not for ReadByte and > WriteByte methods. > > The most efficient implementation would be to directly use the same > buffer as Read and Write uses and move the common buffer > filling/flushing functionality into helper methods (or inlined if only a > few lines could be shared). > > Also note that assuming a good FileStream (or any other already buffered > stream) implementation BufferedStream cannot perform better, so if you > know that your underlaying stream is already buffered, you shouldn't > wrap it in a BufferedStream. > > The idea behind BufferedStream is that you access the stream in small > chunks (smaller than bufferSize) so I believe that the performance > should be optimized for cases when the data being read is already in > buffer and for the cases when the data being written is written to the > buffer. Of course using a fixed one-byte array would speed up the > operation but to maximize the buffered performance ReadByte should not > directly call Read, at least not in the case when data is available in > the internal buffer. > > Kornél > > Alan McGovern wrote: >> Alternatively you could just allocate and retain a 1 byte array inside >> the BufferedStream class and constantly re-use it. BinaryReader already >> uses this approach. As BufferedStream is sealed, the exact approach used >> doesn't particularly matter as the user can't tell the difference. >> >> Would any of the other Stream subclasses benefit from similar >> optimisations? >> >> Alan. >> >> On Sun, Jan 10, 2010 at 3:35 PM, Tom Philpot > <mailto:tom.phil...@logos.com>> wrote: >> >>It looks like the implementation of ReadByte and WriteByte in >>BufferedStream follow the default behavior for Stream by allocating >>a 1-byte array and then calling Read() or Write(). This is exactly >>what the MSDN docs for ReadByte and WriteByte ask implementers NOT >>to do: >> >>> From >> http://msdn.microsoft.com/en-us/library/system.io.stream.readbyte.aspx >>Notes to Implementers: >> >>The default implementation on Stream creates a new single-byte array >>and then calls Read. While this is formally correct, it is >>inefficient. Any stream with an internal buffer should override this >>method and provide a much more efficient version that reads the >>buffer directly, avoiding the extra array allocation on every call. >> >>Granted, most people don't really ever read one byte at a time from >>a Stream, but in our case, we need to. >> >>In my simple tests, reading 1.5 GB of data using ReadByte from >>BufferedStream versus FileStream yielded the following the following >>results (Late 2008 MacBook 13.3" 2.0 Ghz, 5400 rpm disk): >>Test #1: >>Using default BufferedStream ReadByte implementation: 763.814 seconds >>Using FileStream ReadByte implementation: 43.53 seconds >> >>Test #2: >>Using default BufferedStream ReadByte implementation: 765.427 seconds >>Using FileStream ReadByte implementation: 42.678 seconds >> >>Obviously the alloc and GC cost of this one byte array is huge. I >>just thought I'd throw this out there in case one of the Mono devs >>(or someone else) wanted to work on a patch before I got a chance to >>submit one sometime on Monday. >> >>Thanks, >>Tom >>___ >>Mono-devel-list mailing list >>Mono-devel-list@lists.ximian.com >><mailto: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
[Mono-dev] Possible regression in gmcs with private const member variables.
Under gmcs r149310 pulled from SVN trunk this morning, I get a warning about
unused const members that did not appear in 147679.
ws1048-snow:monoscripts tom.philpot$ /opt/mono-r149310/bin/gmcs
~/CompilerTest.cs
/Users/tom.philpot/CompilerTest.cs(18,30): warning CS0169: The private constant
`Application.CompilerTest.c_strFoo' is never used
Compilation succeeded - 1 warning(s)
ws1048-snow:monoscripts tom.philpot$ /opt/mono-r147679/bin/gmcs
~/CompilerTest.cs
ws1048-snow:monoscripts tom.philpot$
Test code is:
namespace Application {
public class CompilerTest {
public CompilerTest() {
m_strPath = System.IO.Path.Combine("/Home/directory",
c_strFoo);
}
public string Path {
get { return m_strPath; }
}
string m_strPath;
const string c_strFoo = "Foo";
public static void Main (string[] args) {
new CompilerTest();
}
}
}
Is this a regression?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
It looks like the implementation of ReadByte and WriteByte in BufferedStream follow the default behavior for Stream by allocating a 1-byte array and then calling Read() or Write(). This is exactly what the MSDN docs for ReadByte and WriteByte ask implementers NOT to do: >From http://msdn.microsoft.com/en-us/library/system.io.stream.readbyte.aspx Notes to Implementers: The default implementation on Stream creates a new single-byte array and then calls Read. While this is formally correct, it is inefficient. Any stream with an internal buffer should override this method and provide a much more efficient version that reads the buffer directly, avoiding the extra array allocation on every call. Granted, most people don't really ever read one byte at a time from a Stream, but in our case, we need to. In my simple tests, reading 1.5 GB of data using ReadByte from BufferedStream versus FileStream yielded the following the following results (Late 2008 MacBook 13.3" 2.0 Ghz, 5400 rpm disk): Test #1: Using default BufferedStream ReadByte implementation: 763.814 seconds Using FileStream ReadByte implementation: 43.53 seconds Test #2: Using default BufferedStream ReadByte implementation: 765.427 seconds Using FileStream ReadByte implementation: 42.678 seconds Obviously the alloc and GC cost of this one byte array is huge. I just thought I'd throw this out there in case one of the Mono devs (or someone else) wanted to work on a patch before I got a chance to submit one sometime on Monday. Thanks, Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WaitAny does not consistently return when waiting on more than one WaitHandle
I¹ve finally gotten around to creating a Bugzilla case for this: https://bugzilla.novell.com/show_bug.cgi?id=561792 Thanks, Tom On 11/25/09 3:59 PM, "Tom Philpot" wrote: > Zoltan, > > Would it help if I created a Mac OS specific bugzilla? Is there someone else > that can test this on Mac? (Geoff N, perhaps)? > > This behavior is the same (i.e., consistently inconsistent) on 10.5 and 10.6 > for what it¹s worth. > > Tom > > On 11/25/09 3:55 PM, "Zoltan Varga" wrote: > >> Hi, >> >> This seems to work fine on linux. >> >> Zoltan >> >> On Thu, Nov 26, 2009 at 12:01 AM, Tom Philpot wrote: >>> We've written a small test case against Mono 2.7 (r146315) that confirms >>> that WaitAny() does not return in a consistent amount of time, or sometimes >>> at all when waiting on more than one WaitHandle. It also appears that there >>> are no test cases in Mono for this case. >>> >>> Our attached program takes 2 arguments. The first is the number of >>> milliseconds to wait before the wait handles are set, the second is the >>> number of milliseconds to wait in before exiting to give the thread pool >>> time to notify. >>> >>> We're running these tests on Mac OS X, if that helps. >>> >>> >>> >>> Example of Failure case: >>> >>> ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 35000 >>> 1 >>> Setup wait handles, sleeping for 35s... >>> Wait2: Calling WaitAny with 2 WaitHandles >>> Wait1: Calling WaitAny with 1 WaitHandle >>> done sleeping. >>> Setting event 2. >>> Sleeping for 10s to see if wait handles respond. >>> Wait1: WaitAny(1) returned 0. >>> >>> >>> Example of Successful case: >>> >>> ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 5000 >>> 1 >>> Setup wait handles, sleeping for 5s... >>> Wait1: Calling WaitAny with 1 WaitHandle >>> Wait2: Calling WaitAny with 2 WaitHandles >>> done sleeping. >>> Setting event 2. >>> Sleeping for 10s to see if wait handles respond. >>> Wait1: WaitAny(1) returned 0. >>> Wait2: WaitAny(2) returned 1. >>> RegisteredWaitForSingleObjectCallback called. >>> >>> >>> ___ >>> Mono-devel-list mailing list >>> Mono-devel-list@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for Processes.c on Mac OSX
The purpose of the loop is because if sysctl fails to alloc enough space in
the second call, proclength is set to the length of data returned, not to
the length of the data that could/should have been returned, so we have to
start over again by passing NULL to sysctl to determine how big proclength
should have been and try again.
Tom
On 12/2/09 4:03 PM, "Miguel de Icaza" wrote:
> Hello,
>
>> The overall patch looks good, but some small changes must be done
>> before the patch can be committed:
>
> In addition to these comments, I fail to see the point of the do/while
> loop, it seems to not be used at all. Can you explain the reason for
> it? I might be missing something important.
>
>>
>>
>> @@ -1489,8 +1489,73 @@
>> }
>> #endif /* UNUSED_CODE */
>>
>> +#ifdef PLATFORM_MACOSX
>> +#include
>> +#include
>> +
>> Move header declarations to the top of the file. It doesn't matter we have
>> other
>> place with this, let's not make it worse.
>>
>>
>> + if (err == 0) {
>> + result = g_malloc (proclength);
>> + if (result == NULL) {
>> +err = ENOMEM;
>> + }
>> + }
>> No need to guard against allocation failure with g_malloc as glib asserts on
>> failure.
>>
>> The same applies to the loop around allocation failure.
>>
>>
>> + free (result);
>> + result = NULL;
>> + *needed = j * sizeof(guint32);
>> You must use g_free paired with g_malloc.
>>
>>
>> I believe the code in process_open_compare is not optimal for OSX as
>> it wastes time following the
>>
>> linux path. Please rework it to be something saner:
>>
>>
>> #if defined(PLATFORM_MACOSX)
>> ...
>>
>> #elif defined (PLATFORM_SOLARIS)
>> #else
>> ...
>> #endif
>>
>>
>>
>>
>> Thanks for the patch,
>>
>> Rodrigo
>>
>>
>>
>> ___
>> 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] DateTimeOffset Test and Patch
Stephen, Did this patch ever get committed? Thanks, Tom On 11/26/09 5:23 AM, "Stephane Delcroix" wrote: > On Wed, 2009-11-25 at 15:04 -0800, Tom Philpot wrote: >> > Here's a patch that resolves an issue of adding or subtracting time from a >> > DateTime which crosses the DST boundary. > > Thanks for the patch, I ran into that issue once then forgot to apply > the patch (that is now lost). Looking at yours and committing. >> > >> > Again, there don't appear to be test cases for this in the Mono test suite. > your test case will make an unit test. > > -s >> > >> > Kudos to Martin Potter on our team for figuring this out. >> > >> > This patch is licensed under MIT/X11. >> > >> > >> > ___ >> > 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 for Processes.c on Mac OSX
Rodrigo,
Thanks for the feedback. Here¹s an updated patch.
Again, this is X11 MIT Licensed.
Tom
On 12/2/09 4:30 AM, "Rodrigo Kumpera" wrote:
> The overall patch looks good, but some small changes must be done before the
> patch can be committed:
>
>
> @@ -1489,8 +1489,73 @@
> }
> #endif /* UNUSED_CODE */
>
> +#ifdef PLATFORM_MACOSX
> +#include
> +#include
> +
> Move header declarations to the top of the file. It doesn't matter we have
> other
> place with this, let's not make it worse.
>
>
> + if (err == 0) {
> + result = g_malloc (proclength);
> + if (result == NULL) {
> +err = ENOMEM;
> + }
> + }
> No need to guard against allocation failure with g_malloc as glib asserts on
> failure.
>
> The same applies to the loop around allocation failure.
>
>
> + free (result);
> + result = NULL;
> + *needed = j * sizeof(guint32);
> You must use g_free paired with g_malloc.
>
> I believe the code in process_open_compare is not optimal for OSX as it wastes
> time following the
>
> linux path. Please rework it to be something saner:
>
>
> #if defined(PLATFORM_MACOSX)
> ...
>
> #elif defined (PLATFORM_SOLARIS)
> #else
> ...
> #endif
>
>
>
> Thanks for the patch,
>
> Rodrigo
>
>
>
>
processes-patch_fixed.txt
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] Patch for Processes.c on Mac OSX
Forgot to mention that this patch is MIT X11 licensed. Tom On 11/30/09 10:03 AM, "Tom Philpot" wrote: > Has anyone had a chance to review this patch for Mac OS X? > > Basically, enumerating processes on Mac OS X doesn't work correctly in Mono > without this patch, but also doesn't always crash because we're malloc'ing > some large random number of bytes pulled from a garbage location in memory. > If that number is huge, we crash, if it's small enough, we silently and > erroneously succeed. > > Tom > > -- Forwarded Message > From: Tom Philpot > Date: Wed, 25 Nov 2009 15:09:41 -0800 > To: "mono-devel-l...@ximian.com" > Subject: [Mono-dev] Patch for Processes.c on Mac OSX > > We have a patch for io-layer/processes.c where Mono on Mac OSX crashes if > trying to lock a named mutex which is not owned by the current process. The > problem is that Mono on Mac does not correctly know how to enumerate > processes. > > The attached program assumes that you have built it, it then launches itself > and takes a lock on a named mutex. The first instance also tries to acquire > the lock and crashes. > > The attached patch fixes the issue for us. > > Again, props to Martin Potter for the discovery and the patch. > > Tom > > This patch is MIT/X11 licensed. > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- End of Forwarded Message > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for Atom10{Item, Feed}Formatter for writing element extensions
I think this patch as well got lost in the shuffle of a long U.S. holiday
weekend as well. Could someone please review and provide some feedback?
Thanks,
Tom
-- Forwarded Message
From: Tom Philpot
Date: Wed, 25 Nov 2009 15:13:03 -0800
To: "mono-devel-l...@ximian.com"
Subject: [Mono-dev] Patch for Atom10{Item, Feed}Formatter for writing
element extensions
Here's a patch for Atom10ItemFormatter and Atom10FeedFormatter which writes
ElementExtensions for the Feed and Item.
This patch is MIT/X11 licenesed and brought to you by Martin Potter.
Tom
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- End of Forwarded Message
Atom10Formatters_patch.txt
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] FW: Patch for Processes.c on Mac OSX
Has anyone had a chance to review this patch for Mac OS X? Basically, enumerating processes on Mac OS X doesn't work correctly in Mono without this patch, but also doesn't always crash because we're malloc'ing some large random number of bytes pulled from a garbage location in memory. If that number is huge, we crash, if it's small enough, we silently and erroneously succeed. Tom -- Forwarded Message From: Tom Philpot Date: Wed, 25 Nov 2009 15:09:41 -0800 To: "mono-devel-l...@ximian.com" Subject: [Mono-dev] Patch for Processes.c on Mac OSX We have a patch for io-layer/processes.c where Mono on Mac OSX crashes if trying to lock a named mutex which is not owned by the current process. The problem is that Mono on Mac does not correctly know how to enumerate processes. The attached program assumes that you have built it, it then launches itself and takes a lock on a named mutex. The first instance also tries to acquire the lock and crashes. The attached patch fixes the issue for us. Again, props to Martin Potter for the discovery and the patch. Tom This patch is MIT/X11 licensed. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- End of Forwarded Message MutexTest.cs Description: Binary data processes-patch.txt 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] WaitAny does not consistently return when waiting on more than one WaitHandle
Zoltan, Would it help if I created a Mac OS specific bugzilla? Is there someone else that can test this on Mac? (Geoff N, perhaps)? This behavior is the same (i.e., consistently inconsistent) on 10.5 and 10.6 for what it¹s worth. Tom On 11/25/09 3:55 PM, "Zoltan Varga" wrote: > Hi, > > This seems to work fine on linux. > > Zoltan > > On Thu, Nov 26, 2009 at 12:01 AM, Tom Philpot wrote: >> We've written a small test case against Mono 2.7 (r146315) that confirms >> that WaitAny() does not return in a consistent amount of time, or sometimes >> at all when waiting on more than one WaitHandle. It also appears that there >> are no test cases in Mono for this case. >> >> Our attached program takes 2 arguments. The first is the number of >> milliseconds to wait before the wait handles are set, the second is the >> number of milliseconds to wait in before exiting to give the thread pool >> time to notify. >> >> We're running these tests on Mac OS X, if that helps. >> >> >> >> Example of Failure case: >> >> ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 35000 >> 1 >> Setup wait handles, sleeping for 35s... >> Wait2: Calling WaitAny with 2 WaitHandles >> Wait1: Calling WaitAny with 1 WaitHandle >> done sleeping. >> Setting event 2. >> Sleeping for 10s to see if wait handles respond. >> Wait1: WaitAny(1) returned 0. >> >> >> Example of Successful case: >> >> ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 5000 >> 1 >> Setup wait handles, sleeping for 5s... >> Wait1: Calling WaitAny with 1 WaitHandle >> Wait2: Calling WaitAny with 2 WaitHandles >> done sleeping. >> Setting event 2. >> Sleeping for 10s to see if wait handles respond. >> Wait1: WaitAny(1) returned 0. >> Wait2: WaitAny(2) returned 1. >> RegisteredWaitForSingleObjectCallback called. >> >> >> ___ >> 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 for Atom10{Item, Feed}Formatter for writing element extensions
Here's a patch for Atom10ItemFormatter and Atom10FeedFormatter which writes ElementExtensions for the Feed and Item. This patch is MIT/X11 licenesed and brought to you by Martin Potter. Tom Atom10Formatters_patch.txt 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 for Processes.c on Mac OSX
We have a patch for io-layer/processes.c where Mono on Mac OSX crashes if trying to lock a named mutex which is not owned by the current process. The problem is that Mono on Mac does not correctly know how to enumerate processes. The attached program assumes that you have built it, it then launches itself and takes a lock on a named mutex. The first instance also tries to acquire the lock and crashes. The attached patch fixes the issue for us. Again, props to Martin Potter for the discovery and the patch. Tom This patch is MIT/X11 licensed. MutexTest.cs Description: Binary data processes-patch.txt 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] DateTimeOffset Test and Patch
Here's a patch that resolves an issue of adding or subtracting time from a DateTime which crosses the DST boundary. Again, there don't appear to be test cases for this in the Mono test suite. Kudos to Martin Potter on our team for figuring this out. This patch is licensed under MIT/X11. DTOTest.cs Description: Binary data datetimeoffset-patch.txt 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] WaitAny does not consistently return when waiting on more than one WaitHandle
We've written a small test case against Mono 2.7 (r146315) that confirms that WaitAny() does not return in a consistent amount of time, or sometimes at all when waiting on more than one WaitHandle. It also appears that there are no test cases in Mono for this case. Our attached program takes 2 arguments. The first is the number of milliseconds to wait before the wait handles are set, the second is the number of milliseconds to wait in before exiting to give the thread pool time to notify. We're running these tests on Mac OS X, if that helps. Example of Failure case: ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 35000 1 Setup wait handles, sleeping for 35s... Wait2: Calling WaitAny with 2 WaitHandles Wait1: Calling WaitAny with 1 WaitHandle done sleeping. Setting event 2. Sleeping for 10s to see if wait handles respond. Wait1: WaitAny(1) returned 0. Example of Successful case: ws1048:Mono Patches tom.philpot$ /opt/mono/bin/mono WaitAnyTest.exe 5000 1 Setup wait handles, sleeping for 5s... Wait1: Calling WaitAny with 1 WaitHandle Wait2: Calling WaitAny with 2 WaitHandles done sleeping. Setting event 2. Sleeping for 10s to see if wait handles respond. Wait1: WaitAny(1) returned 0. Wait2: WaitAny(2) returned 1. RegisteredWaitForSingleObjectCallback called. WaitAnyTest.cs 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] Sgen GC for Mac
Apparently Mono's new garbage collector requires __thread (pthread thread local storage) which is not supported by Mac OS X. configure: error: The SGEN garbage collector depends on a working __thread implementation, and either --with-thread=pthread was passed to configure, or the configure test for __thread failed. Since Mac doesn't support thread local storage (TLS) via __thread, are there ever plans to implement Sgen GC on Mac? For those interested, here's some historical reading on this for those interested: http://lists.apple.com/archives/Darwin-dev/2008/Jul/msg1.html http://lists.apple.com/archives/darwin-dev/2005/Sep/threads.html#5 Particularly interesting is Paolo Molaro in here: http://lists.apple.com/archives/darwin-dev/2005/Sep/msg00011.html Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpOnly and Expires not handled by CookieContainer.SetCookies(Uri, string)
While troubleshooting a web service authentication problem our app is having, I noticed that CookieContainer.SetCookies(Uri, string) has a few problems. 1) It assumes that the Set-Cookie header only has one cookie in it, since it does not account for several comma separated cookies (as the MSDN docs state, and RFC 2109 section 4.2.2) 2) It does not properly set Cookie.Expires or Cookie.HttpOnly (for .NET 2.0). The current implementation will assume that expires=... specifies a new cookie. Similarly, HttpOnly will cause the CookieContainer to throw an exception when the cookie is being created since it assumes HttpOnly is a cookie name with no value. 3) I also noticed most of the CookieContainer tests are marked as "NotWorking". Is CookieContainer really that broken, or am I missing something? Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for XmlConvert and System.ServiceModel.Syndication
Can I request that we apply this patch to 2.6 as well as SVN? Thanks, Tom On 10/2/09 2:17 PM, "David Mitchell" wrote: > I would very much appreciate it if someone would review/apply this patch. > Apologies for being too lazy to write a test case (the changes are pretty > simple). > > Here¹s what you¹ll find: > - Calling XmlConvert.ToDateTimeOffset (all overloads) no longer results in a > stack overflow. Moreover, the return value should actually be correct. > - Atom10ItemFormatter now uses XmlConvert.ToDateTimeOffset to parse the > publish date and last updated time. > - Atom10FeedFormatter¹s ReadItem returns real values (specifying a > SyndicationItem in the constructor for Atom10ItemFormatter doesn¹t work right > now: it eventually gets overwritten with a new value). > > Thanks! > --Dave > > ___ > 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] Process.GetCurrentProcess().Modules crashes on Mac OS X Snow Leopard
Since Romain¹s fix didn¹t seem to fix the issue, I did some digging today. This seems to fix the issue sufficiently for us on Snow Leopard. Apparently not all dylibs on Snow Leopard have a __data section. For example Cocoa on Snow Leopard does not, but Cocoa on Leopard does. otool -l /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa | grep __data Please have at the attached patch and see if there are any issues. I¹m contributing this under the MIT/X11 license. Thanks, Tom On 8/31/09 5:01 PM, "Tom Philpot" wrote: > https://bugzilla.novell.com/show_bug.cgi?id=533893 > > Romain Tartière has suggested a fix in the comments that would probably work > for MacOSX. > > Any chance of getting this merged into SVN? > > Thanks, > Tom > > > On 8/24/09 3:00 PM, "Rodrigo Kumpera" wrote: > >> 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 -- End of Forwarded Message patch_bug_533893.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] Mono SVN doesn't build on Mac OSX Snow Leopard
We were able to get Mono SVN building on Snow Leopard with the following CFLAGS: CFLAGS="-m32 -Dmacosx -D_XOPEN_SOURCE" On 9/8/09 5:22 PM, "Geoff Norton" wrote: > I have some experimental patches for amd64-darwin-mono, but not ready > yet. For now you should set the CFLAGS="-m32" > > -g > > On 8-Sep-09, at 8:14 PM, Tom Philpot wrote: > >> The primary reason seems to be that the default version of gcc on Snow >> Leopard, 4.2.1, no longer defines __i386__. gcc 4.2.1 defines >> __x86_64__. >> >> I started down the path of modifying some of the #defines to correctly >> target DARWIN and use __x86_64__, but I ran into trouble building >> aot-runtime.c because mini.h wanted to use the -x86 sources not the >> amd64 >> sources. >> >> Has anyone else tried to build Mono from SVN on Snow Leopard? >> >> Thanks, >> Tom >> >> >> >> >> ___ >> 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] Error Normalizing Arabic Strings
I forgot to mention what happens. You get an unhandled exception.
We're planning on writing a process that goes through and finds a bunch of
these cases so we can submit a huge bug report of all the cases we know of
where Mono differs from say ICU's normalization.
ws1048:~ tom.philpot$ gmcs ArabicBug.cs -out:ArabicBug.exe
ws1048:~ tom.philpot$ mono --debug ./ArabicBug.exe
Unhandled Exception: System.SystemException: Internal error: should not
happen.
at Mono.Globalization.Unicode.Normalization.Combine
(System.Text.StringBuilder sb, Int32 start, Int32 checkType) [0x0]
at Mono.Globalization.Unicode.Normalization.Compose (System.String source,
Int32 checkType) [0x0]
at Mono.Globalization.Unicode.Normalization.Normalize (System.String
source, Int32 type) [0x0]
at System.String.Normalize (NormalizationForm normalizationForm) [0x0]
at Test.NormalizationTest_Arabic.TestNormalization () [0x0]
at Test.NormalizationTest_Arabic.Main () [0x0]
On 9/11/09 3:36 PM, "Tom Philpot" wrote:
> I just discovered more Unicode Normalization Bugs in Mono SVN.
>
>
> using System;
> using System.Text;
>
> namespace Test
> {
>
> public class NormalizationTest_Arabic {
>
> public void TestNormalization() {
> char[] originalChars = new char [] { '\u064A', '\u064F',
> '\u0648', '\u0654', '\u0652', '\u064A', '\u064F', '\u0648', '\u0654' };
>
> // Results from http://minaret.info/test/normalize.msp
> char[] formC = new char [] { '\u064A', '\u064F', '\u0624',
> '\u0652', '\u064a', '\u064f', '\u0624' };
> char[] formD = new char [] { '\u064A', '\u064F', '\u0648',
> '\u0652', '\u0654', '\u064a', '\u064f', '\u0648', '\u0654' };
> char[] formKC = new char [] { '\u064A', '\u064F', '\u0624',
> '\u0652', '\u064a', '\u064f', '\u0624' };
> char[] formKD = new char [] { '\u064A', '\u064F', '\u0648',
> '\u0652', '\u0654', '\u064a', '\u064f', '\u0648', '\u0654' };
>
> string str = new string(originalChars);
>
> string strNormalizedC = str.Normalize(NormalizationForm.FormC);
> string strNormalizedD = str.Normalize(NormalizationForm.FormD);
> string strNormalizedKC =
> str.Normalize(NormalizationForm.FormKC);
> string strNormalizedKD =
> str.Normalize(NormalizationForm.FormKD);
> }
>
> public static void Main()
> {
> NormalizationTest_Arabic nta = new NormalizationTest_Arabic();
> nta.TestNormalization();
> }
> }
>
> ___
> 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] Error Normalizing Arabic Strings
I just discovered more Unicode Normalization Bugs in Mono SVN.
using System;
using System.Text;
namespace Test
{
public class NormalizationTest_Arabic {
public void TestNormalization() {
char[] originalChars = new char [] { '\u064A', '\u064F',
'\u0648', '\u0654', '\u0652', '\u064A', '\u064F', '\u0648', '\u0654' };
// Results from http://minaret.info/test/normalize.msp
char[] formC = new char [] { '\u064A', '\u064F', '\u0624',
'\u0652', '\u064a', '\u064f', '\u0624' };
char[] formD = new char [] { '\u064A', '\u064F', '\u0648',
'\u0652', '\u0654', '\u064a', '\u064f', '\u0648', '\u0654' };
char[] formKC = new char [] { '\u064A', '\u064F', '\u0624',
'\u0652', '\u064a', '\u064f', '\u0624' };
char[] formKD = new char [] { '\u064A', '\u064F', '\u0648',
'\u0652', '\u0654', '\u064a', '\u064f', '\u0648', '\u0654' };
string str = new string(originalChars);
string strNormalizedC = str.Normalize(NormalizationForm.FormC);
string strNormalizedD = str.Normalize(NormalizationForm.FormD);
string strNormalizedKC =
str.Normalize(NormalizationForm.FormKC);
string strNormalizedKD =
str.Normalize(NormalizationForm.FormKD);
}
public static void Main()
{
NormalizationTest_Arabic nta = new NormalizationTest_Arabic();
nta.TestNormalization();
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono SVN doesn't build on Mac OSX Snow Leopard
The primary reason seems to be that the default version of gcc on Snow Leopard, 4.2.1, no longer defines __i386__. gcc 4.2.1 defines __x86_64__. I started down the path of modifying some of the #defines to correctly target DARWIN and use __x86_64__, but I ran into trouble building aot-runtime.c because mini.h wanted to use the -x86 sources not the amd64 sources. Has anyone else tried to build Mono from SVN on Snow Leopard? Thanks, Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gmcs fails with errors, but no error messages
Marek, Thanks for the response, but that doesn't give any more information. Do you think running in gdb would help? Tom On 9/2/09 1:38 AM, "Marek Safar" wrote: > Hi, >> I have a csproj which builds successfully under gmcs r136341, but which >> fails under later versions including gmcs r141081. With the latest version >> of gmcs, I get the following failure, but no description of the issue: >> >> Compilation failed: 2 error(s), 0 warnings >> ws1048:~ tom.philpot$ >> >> >> Building the same project in Monodevelop gives the following error >> description: >> "/var/folders/4M/4Mzzhf4qH-S3b733dx5BflaDzvM/-Tmp-/tmp61fbc732.tmp" >> >> When I look for this file, it is missing. >> >> In short, there are two orthogonal issues: 1) gmcs is failing on code that >> previously worked and 2) gmcs is not reporting errors when it is failing in >> this case. >> >> Any tips on how I can debug this would be appreciated. >> > Try to run gmcs with --fatal option > > Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Exceptions-x86.c r140989 causes exceptions.exe test to crash on Mac x86
While trying to rebuild the latest Mono SVN, I noticed that the exceptions.exe was crashing during "make check". Digging a little deeper I reverted the latest change to exceptions-x86.c (svn update -r PREV mono/mono/mini/exceptions-x86.c) and everything passed. The crash from the test case using r of exceptions-x86.c is as follows: Test run: image=/Users/tom.philpot/External/mono-project/mono/mono/mini/exceptions.exe , opts= Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x4> at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) <0x> at Tests.test_0_byte_cast () <0x00318> Native stacktrace: 0 mono0x0008e0da mono_handle_native_sigsegv + 266 1 mono0x6eca mono_sigsegv_signal_handler + 298 2 libSystem.B.dylib 0x949402bb _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 Debug info from gdb: warning: Trying to remove a section from the ordered section list that did not exist at 0x29c000. Attaching to process 53961. Reading symbols for shared libraries . done Reading symbols for shared libraries done 0x948f7f95 in read$UNIX2003 () 4 process 53961 thread 0x2703 0x948d42c2 in semaphore_wait_trap () 3 process 53961 thread 0x2303 0x948db46e in __semwait_signal () 2 process 53961 thread 0x1103 0x948d4286 in mach_msg_trap () * 1 process 53961 thread 0x717 0x948f7f95 in read$UNIX2003 () Thread 4 (process 53961 thread 0x2703): #0 0x948d42c2 in semaphore_wait_trap () #1 0x000f8013 in finalizer_thread (unused=0x0) at gc.c:1014 #2 0x001851ba in start_wrapper (data=0x60f4a0) at threads.c:657 #3 0x001b6225 in thread_start_routine (args=0x5dc434) at wthreads.c:286 #4 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #5 0x94905155 in _pthread_start () #6 0x94905012 in thread_start () Thread 3 (process 53961 thread 0x2303): #0 0x948db46e in __semwait_signal () #1 0x948db2ef in nanosleep$UNIX2003 () #2 0x00199b10 in collection_thread (unused=0x0) at collection.c:34 #3 0x94905155 in _pthread_start () #4 0x94905012 in thread_start () Thread 2 (process 53961 thread 0x1103): #0 0x948d4286 in mach_msg_trap () #1 0x948dba7c in mach_msg () #2 0x000c0dc4 in mach_exception_thread (arg=0x0) at mini-darwin.c:131 #3 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #4 0x94905155 in _pthread_start () #5 0x94905012 in thread_start () Thread 1 (process 53961 thread 0x717): #0 0x948f7f95 in read$UNIX2003 () #1 0x0008e1cb in mono_handle_native_sigsegv (signal=11, ctx=0xbfffec38) at mini-exceptions.c:1560 #2 0x6eca in mono_sigsegv_signal_handler (_dummy=11, info=0xbfffebf8, context=0xbfffec38) at mini.c:4583 #3 #4 0x0005a05e in mono_fconv_ovf_u8 (v=0) at jit-icalls.c:860 #5 0x016a23e7 in ?? () #6 0x016a1c49 in ?? () #7 0x00067d7d in mini_regression [inlined] () at driver.c:427 #8 0x00067d7d in mono_main (argc=16, argv=0xb0ec) at driver.c:484 #9 0x1ff6 in start () = 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. = ___ 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().Modules crashes on Mac OS X Snow Leopard
https://bugzilla.novell.com/show_bug.cgi?id=533893 Romain Tartière has suggested a fix in the comments that would probably work for MacOSX. Any chance of getting this merged into SVN? Thanks, Tom On 8/24/09 3:00 PM, "Rodrigo Kumpera" wrote: > 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
[Mono-dev] Building Mono.framework snapshot on Mac OSX
I realize this question has been asked before [1], but I can't find a satisfactory answer. Is it possible to build Mono.framework from the scripts provided in release/ without having access to the Novell build servers? Can I use the scripts to build from my local SVN copy? I ask because we run embedded and link against Mono.framework. 2.4.2.3 has some Unicode normalization bugs that Atsushi has fixed in SVN which cause our app to crash.[1] Also, 2.4.2.3 has a crasher bug with Process.GetModules on Snow Leopard that we need fixed as well.[2],[3] We need to be able to test our code against SVN snapshots more recent than 2.4.2.3 and to do that, the easiest thing to do would be to would be to have a recent Mono.framework snapshot. Thanks in advance, Tom -- [1] http://lists.ximian.com/pipermail/mono-osx/2008-July/001514.html [2] http://lists.ximian.com/pipermail/mono-devel-list/2009-June/032453.html [3] http://lists.ximian.com/pipermail/mono-devel-list/2009-August/032841.html ___ 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
[Mono-dev] CS0411 error with nullable enum
One more generics error for you all. The following compiles on Windows .NET,
but Mono seems to have issues. Again, this is compiling against SVN HEAD.
I¹ll file a Bugzilla report in the morning.
Tom
using System;
using System.Collections.Generic;
namespace Test
{
public enum Enum
{
One,
Two,
}
class CompilerTest
{
protected static int DoSomething(string s, T t, ref T t2)
{
return 0;
}
// .NET 3.5 infers Enum from T, Mono is confused
public static void ThisDoesNotWork()
{
// Nullable does not work
Enum? e = Enum.One;
DoSomething("abc", Enum.Two, ref e);
}
public static void ThisWorksFine()
{
Enum e = Enum.One;
DoSomething("abc", Enum.Two, ref e);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gmcs compiler bug with generics
This is filed under Bug #523683.
On 7/20/09 4:08 PM, "Tom Philpot" wrote:
> We found the following bug with gmcs ( r138189). I¹ll be filling a bugzilla
> report as well, but thought I¹d post it here in case someone wants a head
> start.
>
> Tom
>
> using System;
> using System.Linq;
> using System.Collections.Generic;
> using System.Collections.ObjectModel;
>
> namespace TestNS
> {
> public class TestCase
> {
> public static int Compare(T[] array1, T[] array2)
> {
> return 0;
> }
>
> public static void DoSomething(Func fn)
> {
> Console.WriteLine(fn(default(T), default(T)));
> }
>
> public static void DoSomethingElse()
> {
> // Does not work
> DoSomething(TestCase.Compare);
> // Does work
> // DoSomething((a, b) => TestCase.Compare(a, b));
> }
> }
> }
>
>
> [ tom.philpot]$ gmcs TestCompiler.cs -out:TestCompiler.dll
> Internal compiler error at TestCompiler.cs(23,36):: exception caught while
> emitting MethodBuilder [TestCase::DoSomethingElse]
>
> Unhandled Exception: Mono.CSharp.InternalErrorException: VerifyArgumentsCompat
> didn't find any problem with rejected candidate Void
> DoSomething[Byte[]](System.Func`3[System.Byte[],System.Byte[],System.Int32])
> at Mono.CSharp.MethodGroupExpr.OverloadResolve (Mono.CSharp.EmitContext ec,
> Mono.CSharp.Arguments& Arguments, Boolean may_fail, Location loc) [0x0]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Gmcs compiler bug with generics
We found the following bug with gmcs ( r138189). I¹ll be filling a bugzilla
report as well, but thought I¹d post it here in case someone wants a head
start.
Tom
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.ObjectModel;
namespace TestNS
{
public class TestCase
{
public static int Compare(T[] array1, T[] array2)
{
return 0;
}
public static void DoSomething(Func fn)
{
Console.WriteLine(fn(default(T), default(T)));
}
public static void DoSomethingElse()
{
// Does not work
DoSomething(TestCase.Compare);
// Does work
// DoSomething((a, b) => TestCase.Compare(a, b));
}
}
}
[ tom.philpot]$ gmcs TestCompiler.cs -out:TestCompiler.dll
Internal compiler error at TestCompiler.cs(23,36):: exception caught while
emitting MethodBuilder [TestCase::DoSomethingElse]
Unhandled Exception: Mono.CSharp.InternalErrorException:
VerifyArgumentsCompat didn't find any problem with rejected candidate Void
DoSomething[Byte[]](System.Func`3[System.Byte[],System.Byte[],System.Int32])
at Mono.CSharp.MethodGroupExpr.OverloadResolve (Mono.CSharp.EmitContext
ec, Mono.CSharp.Arguments& Arguments, Boolean may_fail, Location loc)
[0x0]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] "make check" crashes on Mac (r137831)
It appears that the tests broke in r137322, since r137319 ³make check² succeeds on Mac. On 7/13/09 7:55 PM, "Tom Philpot" wrote: > While building mono r137831 from SVN, I get a crash in ³make check². (I had a > coworker duplicate this as well with a fresh checkout of mono and mcs). > > I built with the following options: > autogen.sh prefix=/opt/mono > > I¹ve attached the error log to the mail. > > I¹ve got a couple of regressions since r136341 we¹re seeing our code that I > was going to try to track down tonight and submit bug reports for, but I can > get the trunk to build > > ___ > 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] "make check" crashes on Mac (r137831)
While building mono r137831 from SVN, I get a crash in ³make check². (I had a coworker duplicate this as well with a fresh checkout of mono and mcs). I built with the following options: autogen.sh prefix=/opt/mono I¹ve attached the error log to the mail. I¹ve got a couple of regressions since r136341 we¹re seeing our code that I was going to try to track down tonight and submit bug reports for, but I can get the trunk to build make_check_errors.txt 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] Unhandled Exception in Normalization.cs Combine()
Atsushi,
Thanks for the fixes. From a cursory test, it appears this fixes our issues
as well. I assumed that Mono was using MbUnit. I'll send you a test case w/o
MbUnit that's more in line with the current Mono test framework when I get
the chance.
Tom Philpot
On 6/19/09 3:04 AM, "Atsushi Eno"
wrote:
> Actually I was wrong at fixing the first "bug" you reported. It was
> actually .NET which is buggy, though unlike older Mono it doesn't result
> in an unhandled exception.
>
> http://demo.icu-project.org/icu-bin/nbrowser?t=\u03B1\u0313\u0345&s=&uv=0
>
> To examine C# implementation, try below:
>
> foreach (char c in "\u03B1\u0313\u0345".Normalize ())
> Console.Write ("{0:X04} ", (int) c);
>
> NET outputs: 03B1 0313 0345
>
> I have a fix that corrects the output as: 1F80
>
> I'll check in the fix soon. With the fix your test prints all "True".
>
> Atsushi Eno
>
>
> Atsushi Eno wrote:
>> Hi Tom, and Tom :)
>>
>> I have tried the Hindle version of the test.
>>
>> Summary: the sample depends on .NET bug; 2 .NET bugs, 1 mono bug.
>>
>> This exactly shows that .NET Normalization is buggy. Here is the
>> result from ICU normalization results:
>> http://demo.icu-project.org/icu-bin/nbrowser?t=\u00e1bc&s=&uv=0
>>
>> i.e. in NFKD, \u00e1bc must be decomposed to \u0061\u0301\u0062\u0063,
>> while .NET returns the same string as the input.
>>
>> The sample code is confusing because it uses "styleName" output
>> to the next input. .NET does not correctly decompose it to
>> \u0061\u0301\u0062\u0063, while Mono is correct. When it ran on mono,
>> it keeps using the correct NFKD as the next input to the following
>> normalizations and hence difference in NFKC (i.e. we have no bug in
>> normalizing NFKC string, unlike the test claims).
>>
>> I have created a bit visible modification below:
>> http://pastebin.ca/1465907
>>
>> Though, there seems a mono bug on NFD-to-NFC and NFKD-to-NFKC
>> composition. I have extracted a simpler test:
>>
>> string s1 = "\u0061\u0301bc";
>> string s2 = "\u00e1bc";
>> Console.WriteLine (s1.Normalize () == s2);
>>
>> *Both* Mono and .NET says "False", but it must be "True". See
>> ICU conversion results:
>> http://demo.icu-project.org/icu-bin/nbrowser?t=\u0061\u0301bc&s=&uv=0
>> Its NFC must be \u00e1\u0062\u0063 (the string s2 above).
>>
>> I'll work on fixing the composition part of the issue.
>>
>> I haven't tried the Philpot version as I have never installed
>> mbunit on this Windows machine - it'd be nicer if the sample just
>> compiles and runs within standard libs to make it possible to
>> integrate our nunit tests.
>>
>> Atsushi Eno
>>
>>
>> Tom Hindle wrote:
>>> Attached small self contained my test case.
>>> I think the output should be 5 trues.
>>>
>>> I getting 2 Trues and 3 Fails. on mono version r136435
>>>
>>> Incidentally .NET returns 5 trues for this test case.
>>>
>>> Is there a Bugzilla entry for this issue?
>>>
>>>
>>>
>>> Also normalization-tables.h is now has windows line endings (CRLF)
>>>
>>> Thanks
>>> Tom
>>>
>>> On Thu, 2009-06-18 at 13:51 -0700, Tom Philpot wrote:
>>>> Here is a revision of the test case I sent earlier to the list that
>>>> doesn't
>>>> rely on any specific encoding (only uses '\u' characters).
>>>>
>>>> Hopefully this will be helpful.
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 6/18/09 1:49 PM, "Tom Hindle" wrote:
>>>>
>>>>> Hi Guys,
>>>>>
>>>>> With regard to recent Normalization changes I have just run our test
>>>>> suite with recent mono r136422 - and are getting a number of
>>>>> regressions.
>>>>>
>>>>>
>>>>> For example:
>>>>>
>>>>> {
>>>>> string styleName = "\u00e1bc";
>>>>> StStyle style = new StStyle();
>>>>> Cache.LangProject.StylesOC.Add(style);
>>>>> style.Name = styleName;
>>>>>
>>>>> FwStyleSheet.StyleInfoCollection styleCollection = new
>>>>> FwStyleSheet.StyleInfoCollection();
>>>>> styleCollection.Add(new BaseStyleInfo(sty
Re: [Mono-dev] Unhandled Exception in Normalization.cs Combine()
Here is a revision of the test case I sent earlier to the list that doesn't
rely on any specific encoding (only uses '\u' characters).
Hopefully this will be helpful.
Tom
On 6/18/09 1:49 PM, "Tom Hindle" wrote:
> Hi Guys,
>
> With regard to recent Normalization changes I have just run our test
> suite with recent mono r136422 - and are getting a number of
> regressions.
>
>
> For example:
>
> {
> string styleName = "\u00e1bc";
> StStyle style = new StStyle();
> Cache.LangProject.StylesOC.Add(style);
> style.Name = styleName;
>
> FwStyleSheet.StyleInfoCollection styleCollection = new
> FwStyleSheet.StyleInfoCollection();
> styleCollection.Add(new BaseStyleInfo(style));
>
> Assert.IsTrue(styleCollection.Contains(styleName.Normalize(NormalizationForm.F
> ormC))); Assert.IsTrue(styleCollection.Contains(styleName.Normalize(Normalizat
> ionForm.FormD))); Assert.IsTrue(styleCollection.Contains(styleName.Normalize
> (NormalizationForm.FormKC))); Assert.IsTrue(styleCollection.Contains(styleName
> .Normalize(NormalizationForm.FormKD)));
> }
>
> is now failing, as well as other larger unit tests.
>
> I will look info this further to try and produce an example test program
> that doesn't contain references to our code base.
>
> Thanks
> Tom
>
> On Thu, 2009-06-18 at 15:01 +0900, Atsushi Eno wrote:
>> Hi,
>>
>> If you mean the test cases by the previous email, then that's what
>> (I said) includes raw native encoding in your land (Latin1?) and is
>> what I cannot read. Replace them all with ASCII representation (\u).
>>
>> Even if the attachment includes encoding (you mean BOMs?), it is
>> not readable in some environment (like the text editor I use on
>> Windows). Let me repeat, Latin1 is not universal. Don't depend on it
>> (if you do).
>>
>> Atsushi Eno
>>
>>
>> Tom Philpot wrote:
>>> Atsushi,
>>>
>>> Thanks for the feedback. For some reason, the Mac when displaying
>>> unicode always composes strings before display. I'll look at the test
>>> case in corlib tomorrow when I get in to work. Would it be helpful for
>>> the test cases if I gave you both the formD bytes and the formC bytes
>>> that I think are correct for the test case I sent? Perhaps the encoding
>>> did not come across in the attachment.
>>>
>>> We have a workaround for the Mac port of our app which would require
>>> overriding string.Normalize to p/invoke to Mac OS X's NSString library
>>> to do normalization. It would work, but we would prefer not to have to
>>> ship a custom build of Mono. The normalization on .NET appears to be
>>> "good enough" for our purposes and we'd just like our Mac version to be
>>> consistent.
>>>
>>> Tom
>>>
>>> -Original Message-
>>> From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com]
>>> Sent: Wed 6/17/2009 7:51 PM
>>> To: Tom Philpot
>>> Cc: mono-devel-l...@ximian.com
>>> Subject: Re: [Mono-dev] Unhandled Exception in Normalization.cs Combine()
>>>
>>> You seem to have embedded raw native encoding in your land that
>>> is *not* understandable in Japan. Anyways the input string you
>>> posted in the previous sample was already in FormC which will
>>> look like "doing nothing" as the conversion results.
>>>
>>> There is a standalone normalization test generated from normalization
>>> conformance test in corlib/Mono.Globalization.Unicode. We fail
>>> about 26000. Far from good, but still better than 35000 on .NET.
>>>
>>> Atsushi Eno
>>>
>>> Tom Philpot wrote:
>>>> Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using
>>>> mono (r136228).
>>>>
>>>> I've attached some test cases which will hopefully help in tracking down
>>>> what doesn't work.
>>>>
>>>> On 6/15/09 1:58 AM, "Atsushi Eno"
>>>> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> It should be now fixed in trunk.
>>>>>
>>>>> Atsushi Eno
>>>>>
>>>>> Atsushi Eno wrote:
>>>>>> I'll have a look. However since 4 years have passed since I wrote it,
>>>>>> I'll have to revisit the spec and will take not a little time.
>>>>>>
>>>>>> Atsushi Eno
>>>>>>
>>>>
>>>
>>>
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
NormTest3.cs
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] Unhandled Exception in Normalization.cs Combine()
Atsushi, Thanks for the feedback. For some reason, the Mac when displaying unicode always composes strings before display. I'll look at the test case in corlib tomorrow when I get in to work. Would it be helpful for the test cases if I gave you both the formD bytes and the formC bytes that I think are correct for the test case I sent? Perhaps the encoding did not come across in the attachment. We have a workaround for the Mac port of our app which would require overriding string.Normalize to p/invoke to Mac OS X's NSString library to do normalization. It would work, but we would prefer not to have to ship a custom build of Mono. The normalization on .NET appears to be "good enough" for our purposes and we'd just like our Mac version to be consistent. Tom -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: Wed 6/17/2009 7:51 PM To: Tom Philpot Cc: mono-devel-l...@ximian.com Subject: Re: [Mono-dev] Unhandled Exception in Normalization.cs Combine() You seem to have embedded raw native encoding in your land that is *not* understandable in Japan. Anyways the input string you posted in the previous sample was already in FormC which will look like "doing nothing" as the conversion results. There is a standalone normalization test generated from normalization conformance test in corlib/Mono.Globalization.Unicode. We fail about 26000. Far from good, but still better than 35000 on .NET. Atsushi Eno Tom Philpot wrote: > Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using > mono (r136228). > > I've attached some test cases which will hopefully help in tracking down > what doesn't work. > > On 6/15/09 1:58 AM, "Atsushi Eno" > wrote: > >> Hi again, >> >> It should be now fixed in trunk. >> >> Atsushi Eno >> >> Atsushi Eno wrote: >>> I'll have a look. However since 4 years have passed since I wrote it, >>> I'll have to revisit the spec and will take not a little time. >>> >>> Atsushi Eno >>> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unhandled Exception in Normalization.cs Combine()
1. updated mono and mcs from svn 2. Did 'make clean' from mcs/class and mono directories 3. Did 'make' from mono directory 4. Did 'sudo make install' from mono WS1048:mono-project tom.philpot$ /opt/mono/bin/mono --version Mono JIT compiler version 2.5 (/trunk/mono r136341 Wed Jun 17 11:53:03 PDT 2009) Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC:Included Boehm (with typed GC) SIGSEGV: normal Notification: Thread + polling Architecture: x86 Disabled: none WS1048:mono-project tom.philpot$ /opt/mono/bin/gmcs --version Mono C# compiler version 2.5.0.0 WS1048:mono tom.philpot$ ls -l /opt/mono/bin/gmcs -rwxr-xr-x 1 root admin 85 Jun 17 12:06 /opt/mono/bin/gmcs* On 6/17/09 11:41 AM, "Robert Jordan" wrote: > Tom Philpot wrote: >> Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using >> mono (r136228). > > Have you updated and rebuilt both mono & mcs trees? > > Robert > > > ___ > 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] Unhandled Exception in Normalization.cs Combine()
Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using mono (r136228). I've attached some test cases which will hopefully help in tracking down what doesn't work. On 6/15/09 1:58 AM, "Atsushi Eno" wrote: > Hi again, > > It should be now fixed in trunk. > > Atsushi Eno > > Atsushi Eno wrote: >> I'll have a look. However since 4 years have passed since I wrote it, >> I'll have to revisit the spec and will take not a little time. >> >> Atsushi Eno >> NormTest3.cs 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] r135520 change to driver.cs causes "Too many open files" on MacOSX for projects with lots of embedded resources
Actually the changes to driver.cs appear to not even include the embedded resources in the generated file now. Our generated .dll with 3000+ embedded resources went from 56 MB with the pre r135520 code to 2.1 MB with the latest code. Tom On 6/16/09 1:26 AM, "Marek Safar" wrote: > Hi Tom, >> We have a .csproj file with 3000 + embedded resources. With the >> current version of driver.cs (r135520 and later) on Mac OS X, we¹re >> getting the following error. >> > It should be fixed in r136205. > > Thanks > Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] r135520 change to driver.cs causes "Too many open files" on MacOSX for projects with lots of embedded resources
We have a .csproj file with 3000 + embedded resources. With the current version of driver.cs (r135520 and later) on Mac OS X, we¹re getting the following error. Unhandled Exception: System.IO.IOException: Too many open files at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x0] at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean isAsync, Boolean anonymous) [0x0] at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access) [0x0] at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess) at Mono.CSharp.Resources+EmbededResource.Emit () [0x0] at Mono.CSharp.Resources.Emit () [0x0] at Mono.CSharp.Driver.Compile () [0x0] at Mono.CSharp.Driver.Main (System.String[] args) [0x0] Build complete -- 1 error, 0 warnings Once I reverted the change from r135520 in driver.cs things started working again. Can someone please revert this change until we find a better work around that doesn¹t break this on Mac OS X? The soft ulimit on num of open files is 256, the hard limit is 1024 by default on Mac OS X. Thanks. Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Unhandled Exception in Normalization.cs Combine()
The following program throws an UnhandledException when trying to normalize
a series of greek characters. I’ve tested this with Mono 2.4.7 and the
latest code from SVN as of about 1 week ago.
The same program works fine under Visual Studio.
I’m new to Unicode, but I thought I’d put this out there to see if anyone
had a quick fix.
using System;
using System.Text;
namespace NormalizationTest
{
class Program
{
static void Main(string[] args)
{
byte[] utf8Bytes = new byte[] {0xCE, 0xB1, 0xCC, 0x93, 0xCD,
0x85};
string strToNormalize =
System.Text.Encoding.UTF8.GetString(utf8Bytes);
Console.WriteLine("Converted from Hex: {0}", strToNormalize);
Console.WriteLine("Composed Normalized String:
IsNormalized(NormalizationForm.FormC) = {0}",
strToNormalize.IsNormalized(NormalizationForm.FormC));
Console.WriteLine("{0}",
strToNormalize.Normalize(NormalizationForm.FormC));
}
}
}
Output ---
WS1048:Debug tom.philpot$ /opt/mono/bin/gmcs NormTest.cs /out:NormTest.exe
&& /opt/mono/bin/mono --debug NormTest.exe
Converted from Hex: ᾀ
Composed Normalized String: IsNormalized(NormalizationForm.FormC) = False
Unhandled Exception: System.SystemException: Internal error: should not
happen.
at Mono.Globalization.Unicode.Normalization.Combine
(System.Text.StringBuilder sb, Int32 start, Int32 checkType) [0x00198] in
/Users/tom.philpot/External/mono-project/mcs/class/corlib/Mono.Globalization
.Unicode/Normalization.cs:206
at Mono.Globalization.Unicode.Normalization.Combine (System.String source,
Int32 start, Int32 checkType) [0x0003c] in
/Users/tom.philpot/External/mono-project/mcs/class/corlib/Mono.Globalization
.Unicode/Normalization.cs:135
at Mono.Globalization.Unicode.Normalization.Compose (System.String source,
Int32 checkType) [0x00011] in
/Users/tom.philpot/External/mono-project/mcs/class/corlib/Mono.Globalization
.Unicode/Normalization.cs:121
at Mono.Globalization.Unicode.Normalization.Normalize (System.String
source, Int32 type) [0x00015] in
/Users/tom.philpot/External/mono-project/mcs/class/corlib/Mono.Globalization
.Unicode/Normalization.cs:392
at System.String.Normalize (NormalizationForm normalizationForm) [0x00023]
in
/Users/tom.philpot/External/mono-project/mcs/class/corlib/System/String.cs:1
442
at NormalizationTest.Program.Main (System.String[] args) [0x0]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
