Re: [Mono-aspnet-list] nginx + multiple fastcgi-mono-server4 instance = WebResource.axd 404 error
Based on the source code of Mono's System.Web.Handlers.AssemblyResourceLoader I think that the implementation is flawed. I am going to describe the problem, but I think that you should file a bug report. Although it is using a hashing algorithm that always results in the same hash for the same script resource, hashes are not generated and stored in the dictionaries unless a link is generated, thus a resource is not available until a link to it was generated by the same AppDomain before. As such even AppDomain restarts can trigger the problem, although a simple refresh on the page fixes it by generating hashes for the web resources that subsequently can be retrieved from the server, provided that there is only one AppDomain (one process, one server) serving the requests. As I see at least the assembly name should be included in the query string, resource hashes can be regenerated based on WebResourceAttributes of the assembly. To prevent loading arbitrary assemblies, the assembly name should be encrypted using the machine key and also should be signed using HMAC to avoid padding oracle vulnerability similar to CVE-2010-3332 that the MS implementation had (encrypted view state, forms authentication cookie, and WebResource.axd were all affected). Kornel On 1/2/2013 12:34 PM, Ovidiu Deac wrote: I'm running nginx which does load balancing over several instances of fastcgi-mono-server4 Apparently when a webresource link is handled by a different fastcgi-mono-server than the one which originally produced the link it returns a 404 error. I have set a persistent machinekey as recommended for webfarms but the problem still remains. Any idea what else could be wrong? If it makes any difference: the application is written with F#/WebSharper and we disabled the session state and the forms authentication. Thanks ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] nginx + multiple fastcgi-mono-server4 instance = WebResource.axd 404 error
If you have reasons to use Mono or you are already using it, then I think that fixing Mono is a more reasonable option than moving to MS .NET. Kornel On 1/2/2013 3:09 PM, Ovidiu Deac wrote: Thanks for the answer. So the short version is that if I want to have multiple instances of the application and do load balancing then I must drop mono and use .NET instead ? Is there any other possibility to achieve load balancing/high availability with mono? On Wed, Jan 2, 2013 at 3:20 PM, Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com wrote: Based on the source code of Mono's System.Web.Handlers.AssemblyResourceLoader I think that the implementation is flawed. I am going to describe the problem, but I think that you should file a bug report. Although it is using a hashing algorithm that always results in the same hash for the same script resource, hashes are not generated and stored in the dictionaries unless a link is generated, thus a resource is not available until a link to it was generated by the same AppDomain before. As such even AppDomain restarts can trigger the problem, although a simple refresh on the page fixes it by generating hashes for the web resources that subsequently can be retrieved from the server, provided that there is only one AppDomain (one process, one server) serving the requests. As I see at least the assembly name should be included in the query string, resource hashes can be regenerated based on WebResourceAttributes of the assembly. To prevent loading arbitrary assemblies, the assembly name should be encrypted using the machine key and also should be signed using HMAC to avoid padding oracle vulnerability similar to CVE-2010-3332 that the MS implementation had (encrypted view state, forms authentication cookie, and WebResource.axd were all affected). Kornel On 1/2/2013 12:34 PM, Ovidiu Deac wrote: I'm running nginx which does load balancing over several instances of fastcgi-mono-server4 Apparently when a webresource link is handled by a different fastcgi-mono-server than the one which originally produced the link it returns a 404 error. I have set a persistent machinekey as recommended for webfarms but the problem still remains. Any idea what else could be wrong? If it makes any difference: the application is written with F#/WebSharper and we disabled the session state and the forms authentication. Thanks ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com mailto:Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] new install stopped working
On 12/30/2012 7:27 PM, DevLOOP wrote: Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed (for security reasons). Details: To enable the details of this specific error message to be viewable, please create a customErrors tag within a web.config configuration file located in the root directory of the current web application. This customErrors tag should then have its mode attribute set to Off. You should follow the instructions in that message to enable displaying a more helpful error message including a stack trace. Using that information you most likely will be able to resolve the problem. You also may want to temporarily use MonoDebug true in you mod_mono configuration to enable line numers in stack traces. Kornel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono not load *.so shared library on server-pc
Hi, On 12/28/2012 12:47 PM, Wang Song wrote: hi, here is my stackoverflow link: http://stackoverflow.com/questions/14064559/mono-not-load-so-shared-library-on-server-pc Looks like your code is calling Path.GetDirectoryName with an empty string argument, like in Path.GetDirectoryName(); As such the exception is most likely not related to .so loading, it just occurs before the .so is being loaded. The stack trace seems to be printed by your application (not an unhandled exception printed by Mono) and you are missing the exception type. You should use mono --debug to execute you app to get line numbers and use pdb2mdb tool to convert your .pdb debug info produced by VS to get line numbers for your app on Mono too. Kornel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] JIT on iOS
Hi, I was thinking about the feasibility of having an interpreter on iOS but making JIT functional would have a higher impact without significantly increasing future maintenance requirements. First I found https://gist.github.com/855607 that has two relatively recent comments at the bottom that basically state that iOS 6 enables changing writable non-executable memory to read-only executable. I also found http://www.stuartcarnie.com/2011/03/executable-pages-in-ios-43.html that summarizes that read-only executable pages are of little use for a JIT producing multi-threaded code. I haven't verified any of the claims because I don't usually develop on iOS and mprotect with PROT_EXEC may not be accepted to the App Store for iOS. I however think that with some clever hacks the current JIT could be used with this W^X policy of iOS: 1. Using per-thread code pools could be used that avoids collisions for code used only on a single tread. 2. Temporarily make non-executable but writable the last page of code pool when adding a new method to avoid consuming too much memory pages. Time spent in non-executable state can be lessened by generating code in a separate buffer and only copying it to the code pool after is finished. 3. Resolve race conditions in the SIGSEGV handler by retrying code execution. To avoid infinite loops IP address must be checked to point to a code pool and code lock should probably be taken to ensure that the page is marked as executable again before retrying. This way code is ultimately able to be executed even when it takes multiple tries. As long as the signal handler is not calling mprotect, only verifies under the code pool that the page is executable, security is not affected. Under low JIT load race conditions occur rarely, while under high JIT load new code pages are allocated frequently, so race conditions quickly stop occurring for any specific function. As a conclusion I think that this could work fine with very little modifications to JIT if PROT_EXEC is indeed supported. I wonder if you have considered this solution or if you have any information regarding the feasibility of using mprotect with PROT_EXEC. Thank you. Kornel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Initialization of array of enum - trying to not use RuntimeInternals.InitializeArray
On 7/23/2012 9:53 AM, Marek Safar wrote: Expanding the initialization is the easiest option how to workaround this .net bug. Because the scope of the bug is quite limited and easy to workaround I don't think it's work adding special handling for it. Microsoft already fixed the issue but I am not sure whether there is a hotfix available for .NET 2.0 I've tried it using .NET 2.0 and 4.0. It works fine on 32-bit, but both versions fail with ArgumentException on x64. (All the patches from Windows Update are applied.) It however works with .NET 4.5 RC on x64. (That is indeed the next release after the the date of their comment on connect.) Note that the workaround is simple: Not to use InitializeArray for enum arrays. Kornel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-aspnet-list] Mono and IHttpHandler
Hi,
You should use Classic (non-Integrated) mode config (system.web rather
than system.webServer). You can try it in IIS as well in Classic
pipeline mode.
You also will have to either map all requests to mono or just Class in
Apache configuration in order to make this work.
Kornel
mbrenn wrote:
I'd like to use XSP or better mod_mono within a .Net-Project using the
IHttpHandler method.
I have the following class (quite simple:
public class Class1 : IHttpHandler
{
public bool IsReusable
{
get { return false; }
}
public void ProcessRequest(HttpContext context)
{
var result =
Yeah
;
var bytes = Encoding.UTF8.GetBytes(result);
context.Response.Write(result);
}
}
This class gets compiled via .Net to IISHost.dll and is put within the
'bin'-Directory of the webroot.
And the following web.config
?xml version=1.0 encoding=UTF-8?
configuration
system.webServer
handlers accessPolicy=Read, Execute, Script
add name=Class path=* verb=*
type=IISHost.Class1
resourceType=Unspecified preCondition=integratedMode /
/handlers
/system.webServer
system.web
compilation defaultLanguage=c# /
/system.web
/configuration
It is working perfectly within IIS. http://127.0.0.1/test/kfdlsa returns
'Yeah'
Within XSP or mod_mono on Apache, I can create an index.aspx which is parsed
and executed perfectly according to .Net-Framework, but it seems to be that
the handler is not included within the mod_mono-Framework.
Is using IHttpHandler really implemented within Mono or shall I use another
approach for collection all Requests to a certain Host and/or virtual
directory?
--
View this message in context:
http://mono.1490590.n4.nabble.com/Mono-and-IHttpHandler-tp4080761p4080761.html
Sent from the Mono - ASP.NET mailing list archive at Nabble.com.
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-dev] mixed-mode assemblies in wine
Hi, Vincent Povirk wrote: My preferred way would be to call exports that Windows calls: - _CorValidateImage on image load - _CorImageUnloading on image unload - _CorExeMain instead of exe entry point - _CorDllMain instaad of dll entry Is there a reason for us to add this to the Wine loader soon? I've been putting it off because I have to ask for someone else to do it. WIndows 2000 does not call any of these and .NET Framework still works, so Wine will work as well. The whole idea behind this is to increase security when using IL-only assemblies. The assemblies are loaded but no native code (not even entry points, TLS initialization) is executed neither is the IAT resolved. _CorValidateImage becomes necessary once you want to load PE32 IL-only images into a 64-bit process. CorValidateImage will convert the PE32 image to PE32+ in memory that is possible (see implementation) and required. CorValidateImage also removes entry point of PE32+ IL-only dlls since IAT was not resolved. This is not required if the loader is not treating IL-only dlls specially. In my opinion these callbacks are quite easy to implement. One unusual thing I noticed is that suspended process and CreateRemoteThread dll injection is not working for managed processes (maybe just IL-only) because _CorExeMain is called by the loader initialization code rather than process initialization code so it will be called on the new thread instead of thread entry point. I also planned to get rid of MonoFixupExe and drop support for mixed-mode assemblies by using mono.exe and introduce a loader that would call CreateProcess on the managed (may be mixed-mode) .exe, inject a loader .dll (or a custom mscoree.dll) by modifying IAT, remove IL-only flag so that the OS loader will not load MS.NET mscorlib.dll, and do inicialization in that loader .dll called by OS loader. This would not affect functionality of mono.dll just would not fixup mscoree.dll by default that also would play more nicely with standalone verifier, dumper, etc. tools and CoreCLR. That's interesting. It would seem (to me) that in this case your mscoree.dll and ours can and should be the same one. The only difference is how libmono is found and loaded. .NET Framework has a single shared mscoree.dll in system32 that selects and loads the appropriate runtime (mscorwks.dll or mscorsvr.dll for .NET Framework 2.0). Each new runtime usually updates mscoree.dll but remains backwards compatible. Most exports of mscoree.dll are most likely simply forwarded to the loaded runtime. When experimenting with the above approach I have used my own mscoree.dll and loaded Mono and worked fine but this is not the way to go on Windows, that's why I have plans to create a loader that would do the hooking. The same loader would work on Wine but you will not need it as Mono will be your native .NET implementation. I also have the impression that implementing .NET Framework functionality in Wine may not be the right architecture. Ideally those belong to Mono. Since I know that Mono does not accept GPL to runtime (requires MIT X11 license or special permissions to Novell; althoug is licensed under GPL) and Wine prefers GPL this may not be suitable. Wine loader should call mscoree.dll just like Windows loader does (system32\mscoree.dll is hardcoded, cannot use your own). If you prefer to keep mscoree.dll code in Wine, then I belive that Wine mscoree.dll should load mono.dll (as it already does) and forward the above five basic exports to mono.dll and implement other exports on its own by calling native Mono API. My only strong reason for wanting mscoree.dll to be in Wine is so that it can load without any Mono present (which is enough to install many apps, and pass tests), and so that it can select between multiple available Mono setups at runtime (in order to cover .NET versions 1.1, 2.0, and 4.0 simultaneously). For that to work, we need a dll that loads Mono dynamically rather than linking to it, and it needs to support both embedding ABI's. mscoree.dll itself is just a loader and forwarder that can and should remain in Wine. (Sorry about not being specific previously.) I however belive that the actual API implementation should be part of Mono because that could be used on Windows as well. Licensing is not an issue. Wine is LGPL, and we can use MIT code. The reverse isn't true, but I think it would be possible to relicense most of Wine's current mscoree code as MIT, since most of that architecture was written by me for CodeWeavers. Still, if you want to work on the .NET embedding API, I think we should find a way to collaborate, in whichever project. coree.c of Mono was written by me and is already MIT licensed. Mono runtime is available under LGPL (I previously have mistaken it for GPL). As a Mono contributor I may be biased but I belive that the best way to collaborate would be to have native .NET embedding API code in Mono
Re: [Mono-dev] mixed-mode assemblies in wine
Hi, I have some unsubmitted modifications to mixed-mode support I made about a year ago. I should revise them and those may improve mixed-mode support. I haven't had time to sort out the verifier conflict but that should be possible and hopefully easy to resolve. My preferred way would be to call exports that Windows calls: - _CorValidateImage on image load - _CorImageUnloading on image unload - _CorExeMain instead of exe entry point - _CorDllMain instaad of dll entry - the C runtime (not the OS) should also call CorExitProcess on normal termination (exit) All of the above functions are (vaguely, from the wrong perspective) documented on MSDN. This would render MonoFixupCorEE unnecessary. I also planned to get rid of MonoFixupExe and drop support for mixed-mode assemblies by using mono.exe and introduce a loader that would call CreateProcess on the managed (may be mixed-mode) .exe, inject a loader .dll (or a custom mscoree.dll) by modifying IAT, remove IL-only flag so that the OS loader will not load MS.NET mscorlib.dll, and do inicialization in that loader .dll called by OS loader. This would not affect functionality of mono.dll just would not fixup mscoree.dll by default that also would play more nicely with standalone verifier, dumper, etc. tools and CoreCLR. I also have the impression that implementing .NET Framework functionality in Wine may not be the right architecture. Ideally those belong to Mono. Since I know that Mono does not accept GPL to runtime (requires MIT X11 license or special permissions to Novell; althoug is licensed under GPL) and Wine prefers GPL this may not be suitable. Wine loader should call mscoree.dll just like Windows loader does (system32\mscoree.dll is hardcoded, cannot use your own). If you prefer to keep mscoree.dll code in Wine, then I belive that Wine mscoree.dll should load mono.dll (as it already does) and forward the above five basic exports to mono.dll and implement other exports on its own by calling native Mono API. Kornél Vincent Povirk wrote: Two very interesting things happened in Mono recently: 1. The implement type compare for 1b assert failure that would usually occur when loading a mixed-mode assembly in Mono was fixed. So whoever did that, thank you. 2. Rodrigo Kumpera added an ENABLE_COREE define, default off, because that code was breaking the verifier. He tells me I can test this by running a hello world program using --security=verifiable. These two changes had the combined effect of getting me to think about mixed-mode assemblies and forcing me to notice all of Mono's coree code and how it works. Apparently the native code in a mixed-mode assembly works like a p/invoke, except that the invoked function is inside the assembly instead of a library export. Before we can call that code, we need the assembly to be loaded using the OS loader, so it's linked properly. But because all assemblies link to mscoree.dll and execute _CorExeMain or _CorDllMain (and the OS does that itself in recent Windows versions), that would load MS .NET. So Mono loads mscoree.dll itself on Windows before it loads any assemblies, and hooks the mscoree functions so they go to implementations in libmono. This makes sense on Windows, but it's no good on Wine, where mscoree.dll loads Mono. I can't work sanely on the unmanaged API in Wine if it's going to be bypassed by Mono half of the time. But we still need Mono to load the assemblies using the OS loader so it can invoke native methods. So I would like to propose that both mixed-mode behaviors (using the OS loader and hooking mscoree) be default off but optionally activated by embedding API calls (which Wine would call), or switches (which mono_main would translate into the appropriate embedding calls). That is, we would have a function that, if called very early on, would load mscoree.dll and do the hooking, and set a flag so that Mono tries to load assemblies using the OS loader. We would have another, independent function that only sets that flag, which Wine would use. (I think we'll also need access to something like mono_image_open_from_module_handle, so we can give Mono the handle to an already-loaded exe file in _CorExeMain.) Does this seem doable? Once that's done, I'd like to get Wine's mscoree.dll to a point where it's on par with Mono's mixed-mode assembly support. What is that support currently used for, and what are you using to test it? AFAICT an ordinary assembly written in managed c++ and compiled with VS will always fail to load in Mono. Do you have any sense of what's required to make assemblies linking msvcrt (my eventual goal) work? I have so far been unable to create a build of Mono that can call native functions without hooking mscoree, so I can't really tell what's going on. There was speculation in a Wine bug that _CorDllMain needs to call some entry points in assemblies, named PostDllMain and PostRawDllMain, but given
Re: [Mono-dev] mixed-mode assemblies in wine
I forgot about the mixed mode Visaul C++ application issue: Mixed-mode code is supported, however the C++ runtime (by MS) assumes some runtime internals (COM interop (may work by now), fixed RVA fields are shared between app domain, and maybe others) that are not supported by the runtime and are not specific to mixed-mode assembly support. Those could be some of them a controversial features as are not portable across little/big endian like the fixed RVA thing. Kornél Kornél Pál wrote: Hi, I have some unsubmitted modifications to mixed-mode support I made about a year ago. I should revise them and those may improve mixed-mode support. I haven't had time to sort out the verifier conflict but that should be possible and hopefully easy to resolve. My preferred way would be to call exports that Windows calls: - _CorValidateImage on image load - _CorImageUnloading on image unload - _CorExeMain instead of exe entry point - _CorDllMain instaad of dll entry - the C runtime (not the OS) should also call CorExitProcess on normal termination (exit) All of the above functions are (vaguely, from the wrong perspective) documented on MSDN. This would render MonoFixupCorEE unnecessary. I also planned to get rid of MonoFixupExe and drop support for mixed-mode assemblies by using mono.exe and introduce a loader that would call CreateProcess on the managed (may be mixed-mode) .exe, inject a loader .dll (or a custom mscoree.dll) by modifying IAT, remove IL-only flag so that the OS loader will not load MS.NET mscorlib.dll, and do inicialization in that loader .dll called by OS loader. This would not affect functionality of mono.dll just would not fixup mscoree.dll by default that also would play more nicely with standalone verifier, dumper, etc. tools and CoreCLR. I also have the impression that implementing .NET Framework functionality in Wine may not be the right architecture. Ideally those belong to Mono. Since I know that Mono does not accept GPL to runtime (requires MIT X11 license or special permissions to Novell; althoug is licensed under GPL) and Wine prefers GPL this may not be suitable. Wine loader should call mscoree.dll just like Windows loader does (system32\mscoree.dll is hardcoded, cannot use your own). If you prefer to keep mscoree.dll code in Wine, then I belive that Wine mscoree.dll should load mono.dll (as it already does) and forward the above five basic exports to mono.dll and implement other exports on its own by calling native Mono API. Kornél Vincent Povirk wrote: Two very interesting things happened in Mono recently: 1. The implement type compare for 1b assert failure that would usually occur when loading a mixed-mode assembly in Mono was fixed. So whoever did that, thank you. 2. Rodrigo Kumpera added an ENABLE_COREE define, default off, because that code was breaking the verifier. He tells me I can test this by running a hello world program using --security=verifiable. These two changes had the combined effect of getting me to think about mixed-mode assemblies and forcing me to notice all of Mono's coree code and how it works. Apparently the native code in a mixed-mode assembly works like a p/invoke, except that the invoked function is inside the assembly instead of a library export. Before we can call that code, we need the assembly to be loaded using the OS loader, so it's linked properly. But because all assemblies link to mscoree.dll and execute _CorExeMain or _CorDllMain (and the OS does that itself in recent Windows versions), that would load MS .NET. So Mono loads mscoree.dll itself on Windows before it loads any assemblies, and hooks the mscoree functions so they go to implementations in libmono. This makes sense on Windows, but it's no good on Wine, where mscoree.dll loads Mono. I can't work sanely on the unmanaged API in Wine if it's going to be bypassed by Mono half of the time. But we still need Mono to load the assemblies using the OS loader so it can invoke native methods. So I would like to propose that both mixed-mode behaviors (using the OS loader and hooking mscoree) be default off but optionally activated by embedding API calls (which Wine would call), or switches (which mono_main would translate into the appropriate embedding calls). That is, we would have a function that, if called very early on, would load mscoree.dll and do the hooking, and set a flag so that Mono tries to load assemblies using the OS loader. We would have another, independent function that only sets that flag, which Wine would use. (I think we'll also need access to something like mono_image_open_from_module_handle, so we can give Mono the handle to an already-loaded exe file in _CorExeMain.) Does this seem doable? Once that's done, I'd like to get Wine's mscoree.dll to a point where it's on par with Mono's mixed-mode assembly support. What is that support currently used for, and what are you using to test
[Mono-dev] [PATCH] BuildProvider.SetVirtualPath is not called when BuildProvider has no BuildProviderAppliesToAttribute
Hi, Please see Bug 643763: https://bugzilla.novell.com/show_bug.cgi?id=643763 I have no write access so please feel free to commit it if you like it. Thank you. Kornel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.PlatformID
Hi, Try looking at Environment.Version in the prod environment. If you get 1.1.x rather than 2.0.x you know what your problem is. Note that only app.config is able to require a specific runtime version, and there is no such thing as a 3.5 runtime (it's 2.0 with extra assemblies versioned to 3.5.x.x). Kornél Nicholas Salerno wrote: It means you're running in the 1.0 profile. If you were running under the 2.0 profile, you'd get 4 (PlatformID.Unix). If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it. Thank you for the explanation. Nicholas -Original Message- From: Jonathan Pryor [mailto:jonpr...@vt.edu] Sent: Monday, September 20, 2010 10:24 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.PlatformID On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote: When I query System.Environment.OSVersion.Platform on Linux I get a value that will equate to 128. Yet, this is not in the source code definition for the PlatformID enum. It means you're running in the 1.0 profile. If you were running under the 2.0 profile, you'd get 4 (PlatformID.Unix). See: http://www.mono-project.com/FAQ:_Technical Quote: The first versions of the framework (1.0 and 1.1) didn't include any PlatformID value for Unix, so Mono used the value 128. The newer framework 2.0 added Unix to the PlatformID enum but, sadly, with a different value: 4 and newer versions of .NET distinguished between Unix and MacOS X, introducing yet another value 6 for MacOS X. Question: is 128 supposed to mean Linux? It means Unix under the 1.x .NET profile; under the .NET 2.0 profile, PlatformID.Unix (4) is returned. I am wondering if there is a better way or if this is all that can be done. Targeting .NET 2.0+ will help (no 128 value), but only so much (there's still distinct PlatformID.Unix and PlatformID.MacOSX values), so preferable (normally) are feature checks, not platform checks. Feature checks are also more useful anyway, as a feature may be added in some version of a platform, and (based on reading years of Dr. GUI articles in MSDN) platform version detection and handling is HARD. You would not believe the number of errors applications make doing that... Also, what if Microsoft suddenly came out of nowhere and said that 128 will map to AIX? I would laugh. A lot. (AIX?! Seriously?) The matter still has a theoretical nature, which can be answered thus: dontworryaboutit. More specifically, Mono 2.6 is the last release with 1.x profile support, and thus is the last version that will return 128 for PlatformID on Unix platforms. (Plus, most actual apps have been 2.0 apps for quite some time.). Mono 2.8 is 2.0+ only, and thus will never return 128. Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes, so even if Microsoft added a new enum value, only mono master will actually receive the value, not 2.6 (or likely 2.8, at this point). Thus, in practice, it's not really worth worrying about. - Jon ___ 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] AssemblyInstaller
Nicholas Salerno wrote: With respect to compatibility with Microsoft's behavior, I have found two bugs in Mono's implementation of installutil: Mono aims to be compatible with MS.NET so you are welcome to fix compatibility issues. Note that if you also provide unit tests that prove that your implementation is corrent and ensure that there will be no regression later, your patches are more likely to be accepted. Both of these bugs I would like to fix because they really break the write once, run everwhere model and I (and company) do not want to maintain two code bases for dealing with Microsoft's way and Mono's way of installers. Mono itself has the same goals. What I am still undecided about is if ManagedInstallerClass uses AssemblyInstaller to get some of the work done. Right now both of these classes are not implemented in Mono and I am wondering if the code in installutil.exe is split amongst the two classes. I have never used AssemblyInstaller but based on the documentation I agree that ManagedInstallerClass should be the core of a command line tool around AssemblyInstaller. Note that this is an implementation detail invisible to the outside world so you don't have to guess how MS.NET does it, you can just implement it the way that makes sense. To summarize: installutil.exe --uses-- ManagedInstallerClass --uses-- AssemblyInstaller installutil.exe Provides command line user interface for ManagedInstallerClass. I think that this is a good design. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Hi,
A COM visible .NET class is a .NET class. If you use it from .NET you
don't see a difference, and there is no difference in the internals
eiher. The only difference is that you can access COM visible classes
using COM interfaces in unmanaged code. This is very much the same as
P/Invoke DLLs/delegates with the additional support for reference
counting and this argument. (HRESULT to exception translation is also
supported for pure non-OOP functions.)
So you don't really have to care about the COM visible attribute just
take advantage of it if you want to.
Mono already has an installutil.exe (I don't know how mutch compatible
it is with that of MS.NET) so the easiest implementation of
ManagedInstallerClass.InstallHelper is to move logic except
version/copyright header from installutil.exe to
ManagedInstallerClass.InstallHelper.
installutil.exe should not be just a couple of lines longer than my
reference implementation in this thread.
If you mean something else on where implementations should fall into
place please be more specific.
Kornél
Nicholas Salerno:
Thank you for the clarification. All that said, it still seems like
ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller.
ManagedInstallerClass is COM visible, which may imply some things.
AssemblyInstaller appears to be a plain old .NET class. I don't have any
objection to ManagedInstallerClass, I'm just trying to understand where
implementations should fall into place.
Nicholas
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Saturday, September 18, 2010 5:04 AM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
static void Main(string[] args)
{
try
{
ManagedInstallerClass.InstallHelper(args);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
Arguments accepted are documented here:
http://msdn.microsoft.com/en-us/library/50614e95.aspx
So all the functionality of installutil.exe should be moved to
ManagedInstallerClass. Even the help screen comes as an exception.
Note that no version headers are not printed by ManagedInstallerClass
that should remain in installutil.exe and some appropriate status code
should be set on return as well.
Based on the following example I belive that
IManagedInstaller.ManagedInstall does exactly the same except that
exceptions are not returned:
class Program
{
static void Main(string[] args)
{
try
{
IManagedInstaller installer = new
ManagedInstallerClass();
StringBuilder sb = new StringBuilder();
foreach (string arg in args)
{
sb.Append('');
sb.Append(arg.Replace(\\,
).Replace(\, \\\));
sb.Append(\ );
}
if (sb.Length 0)
sb.Remove(sb.Length - 1, 1);
installer.ManagedInstall(sb.ToString(), 0);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
A search for hInstall in Platform SDK headers resulted in matches only
from MsiQuery.h. So that method is most likely used by Windows Installer
and I would guess that at least errors are reported using hInstall
rather than exceptions.
Kornél
Nicholas Salerno write:
Vincent Povirk wrote:
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
The ManagedInstallerClass is scarcely documented in MSDN (unlike the other
classes in the System.Configuration.Install namespace). Also, the
description states that the class is not meant to be directly used by one's
code. I don't know much about this ManagedInstallerClass other than it
doesn't seem to fit with the model established by the Installer class. It
doesn't derive from Installer. It implements IManagedInstaller, an
interface I don't know much about.
I am familiar with the Installer class that derives from Component and is
meant to be subclassed. The AssemblyInstaller class seems to be the class
to use if one wants
Re: [Mono-dev] AssemblyInstaller
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
static void Main(string[] args)
{
try
{
ManagedInstallerClass.InstallHelper(args);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
Arguments accepted are documented here:
http://msdn.microsoft.com/en-us/library/50614e95.aspx
So all the functionality of installutil.exe should be moved to
ManagedInstallerClass. Even the help screen comes as an exception.
Note that no version headers are not printed by ManagedInstallerClass
that should remain in installutil.exe and some appropriate status code
should be set on return as well.
Based on the following example I belive that
IManagedInstaller.ManagedInstall does exactly the same except that
exceptions are not returned:
class Program
{
static void Main(string[] args)
{
try
{
IManagedInstaller installer = new
ManagedInstallerClass();
StringBuilder sb = new StringBuilder();
foreach (string arg in args)
{
sb.Append('');
sb.Append(arg.Replace(\\,
).Replace(\, \\\));
sb.Append(\ );
}
if (sb.Length 0)
sb.Remove(sb.Length - 1, 1);
installer.ManagedInstall(sb.ToString(), 0);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
A search for hInstall in Platform SDK headers resulted in matches only
from MsiQuery.h. So that method is most likely used by Windows Installer
and I would guess that at least errors are reported using hInstall
rather than exceptions.
Kornél
Nicholas Salerno write:
Vincent Povirk wrote:
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
The ManagedInstallerClass is scarcely documented in MSDN (unlike the other
classes in the System.Configuration.Install namespace). Also, the
description states that the class is not meant to be directly used by one's
code. I don't know much about this ManagedInstallerClass other than it
doesn't seem to fit with the model established by the Installer class. It
doesn't derive from Installer. It implements IManagedInstaller, an interface
I don't know much about.
I am familiar with the Installer class that derives from Component and is
meant to be subclassed. The AssemblyInstaller class seems to be the class to
use if one wants to programmatically install and uninstall .NET components
(without having to execute shell commands to instalutil). I do this in
Windows.
If nobody has any objections I would like to submit a patch that implements
the AssemblyInstaller class.
Nicholas
-Original Message-
From: Vincent Povirk [mailto:madewokh...@gmail.com]
Sent: Friday, September 17, 2010 10:41 PM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
___
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] mscorlib.dll not unloaded on windows
This is very strange since no more than a single mscorlib.dll should be loaded no matter how many AppDomians you have. Could you please send me more details about multiple mscolib.dlls: - are they loaded as DLLs or just file handles? - do they have exactly (string comparison, not considering .., links, etc.) the same full path names? Thank you. Kornel Ignas wrote: I haven't attached a sample but test scenario is really simple. Init mono, create child app domain, load assembly, unload domain, cleanup mono, observe how mscorlib.dll is still loaded (at least on Windows). I can tell that by looking at Process Explorer utility which shows that mscorlib.dll is still memory mapped. After every consecutive iteration one more mscorlib.dll is loaded until process runs out of virtual memory. Which is really bad for our browser plugin (Unity Web Player). Is this a known issue? I can make it go away by manually calling mono_assembly_close() on corlib but not sure if this is safe and at which point it is safe. Before mono_runtime_cleanup() or after? Thanks, Ignas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
I'm just trying to implement /nostdlib: http://msdn.microsoft.com/en-us/library/fa13yay7.aspx And I belive that having API for setting assembly aliases would be a good solution. Of course LoadMscorlib is not a bug, it's just redundant. The current AssemblyResolve is able to do that just fine. If there was an assembly alias feature, LoadMscorlib was even more redundant. Regards, Kornél Jeroen Frijters wrote: LoadMscorlib was designed to meet your very specific needs of being able to load mscorlib.dll from a specified file. Any API designed without a very specific use case is doomed, so I consider this a feature not a bug. I don't understand what problem you are trying to solve, so maybe we should back up a little and talk about that first. Regards, Jeroen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi,
If I look at it form an API design point of view netiher LoadMscorlib
nor SetMscorlib are good.
LoadMscorlib was designed to meet your very specific needs of being able
to load mscorlib.dll from a specified file.
SetMscorlib would remove the restriction of loading from the file and
also would be future proof in the sense that it will continue to be
compatible with new assembly loading/creating methods and new overloads
of existing methods without any modification required.
As I see the only was mscorlib.dll could be compiled is that you don't
load another mscorlib.dll in DefineDynamicAssembly or in AssemblyBuilder
constructor. This would be the defined behavior. Right not I cannot
think of any possible requirement for loading mscorlib.dll during
DefineDynamicAssembly. Since mscorlib.dll is a corner case if you will
have to load mscolib.dll anyway intorducing another solution would only
break a marginal set of all the use cases (mainly mcs when building
mscorlib.dll) so such a breaking change would be acceptable. And I think
that if such a requirement would be introduced that would be a breaking
change in MS.NET as well.
As a conclusion I think that there are only two properly designed solutions:
1. Remove LoadMscorlib, make HasMscorlib internal, and rely on
AssemblyResolve event handler.
2. Remove LoadMscorlib, remove HasMscorlib, and add two new methods:
__AddAssembly(string refname, Assembly asm)
__TryGetAssembly(string refname, out Assembly asm)
The first solution is very straightforward, and I've attached a patch
for the second one (it's very straightforwad as well but was easier to
express myself by using a patch).
I consider the second one to be a more proper solution because compiler
writers usually prefer to load a set of assemblier themselves rather
than rely on automatic assembly resolution. Since Universe design in
based on mapping System.Types to IKVM.Reflection.Types, compiler writers
might actually use typeof for other assemblies (not just mscorlib.dll)
and they might want those assembiles to be resolved to their preferred
assembly. An example for such a behavior is a VB.NET compiler that has
its own Microsoft.VisualBasic.dll runtime library treated very similar
to how mscorlib.dll is treated by a C# compiler. VB runtime is written
in VB and a /novbruntimeref option is required to build the runtime.
Regards,
Kornél
Jeroen Frijters wrote:
Please see the attached patch.
I belive that this is actually an easier and cleaner solution than the
current one.
I disagree. You have to look at it from an API development point of view. This
creates a huge window for undefined behavior and dependencies on implementation
specifics, between calling DefineDynamicAssembly and SetMscorlib. It also makes
it impossible for DefineDynamicAssembly (or the AssemblyBuilder constructor) to
do anything that requires mscorlib (and who knows, maybe some future change to
reflection will require this).
Regards,
Jeroen
Index: Universe.cs
===
RCS file: /cvsroot/ikvm/ikvm/reflect/Universe.cs,v
retrieving revision 1.13
diff -u -r1.13 Universe.cs
--- Universe.cs 7 May 2010 16:35:47 - 1.13
+++ Universe.cs 9 May 2010 10:26:13 -
@@ -387,33 +387,22 @@
get { return
typeof_System_Security_Permissions_SecurityAction ??
(typeof_System_Security_Permissions_SecurityAction =
Import(typeof(System.Security.Permissions.SecurityAction))); }
}
- public bool HasMscorlib
- {
- get { return importedTypes.Count != 0 ||
assembliesByName.Count != 0; }
- }
-
public event ResolveEventHandler AssemblyResolve
{
add { resolvers.Add(value); }
remove { resolvers.Remove(value); }
+ }
+
+ public void __AddAssembly(string refname, Assembly asm)
+ {
+ assembliesByName.Add(refname, asm);
}
- public void LoadMscorlib(string path)
- {
- if (HasMscorlib)
- {
- throw new InvalidOperationException();
- }
- Assembly asm = LoadFile(path);
- if (asm.FullName != typeof(object).Assembly.FullName)
- {
- // make the current mscorlib full name an alias
for the specified mscorlib,
- // this ensures that all the runtime built in
type are resolved against the
- // specified mscorlib.
-
assembliesByName.Add(typeof(object).Assembly.FullName, asm);
- }
- }
-
+ public bool __TryGetAssembly(string refname, out Assembly asm)
+
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi,
Thank you for fixing them.
I've just realized that DefineDynamicAssemblyImpl should not hardcode
the name mscorlib since C# compiler is able to us any name when
compiling with nostdlib.
Note that a solution would be to modify (and possibliy rename to
SetMscorlib) LoadMscorlib so that it accepts an Assembly rather than a
path. It should allow the case when assembliesByName and assemblies only
contain the specified assembly.
Kornél
Jeroen Frijters wrote:
Hi Kornél,
Thanks. Fixed all three issues.
Regards,
Jeroen
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Friday, May 07, 2010 6:08 PM
To: Jeroen Frijters
Cc: mono-devel
Subject: Re: Porting mcs to IKVM.Reflection
Hi Jeroen,
Thank you for the fixes.
New problems after the modifications:
SetCustomAttribute now fails for example for DllImportAttribute when
building mscorlib.dll because ReadFixedArg calls GetEnumUnderlyingType
and CheckBaked fails.
AssemblyKeyFileAttribute and AssemblyKeyNameAttribute should not be
considered pseudo custom attributes because even MS csc.exe emits those
attributes and Debug.Assert fails.
Also note that according to my tests AssemblyHashAlgorithm.None is
changed to AssemblyHashAlgorithm.SHA1 when setting the assembly name
because GetName returns AssemblyHashAlgorithm.SHA1 (rather than only
when calling Save).
Kornél
Jeroen Frijters wrote:
Hi Kornél,
This has now been fixed.
Thanks,
Jeroen
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Friday, May 07, 2010 10:33 AM
To: Jeroen Frijters
Cc: Marek Safar; mono-devel; Miguel de Icaza
Subject: Re: Porting mcs to IKVM.Reflection
Hi,
Thank you for applying/enhacing the patches. I'll check it out.
This code will work on both of Mono and MS.NET, but will fail without
the WriteGenericSignature patch:
AssemblyBuilder ab =
AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(myassembly), AssemblyBuilderAccess.Save);
ModuleBuilder mb = ab.DefineDynamicModule(myassembly,
myassembly.dll);
TypeBuilder tb = mb.DefineType(mytype, TypeAttributes.Public);
tb.DefineGenericParameters(new string[] { T, U });
ConstructorBuilder cb =
tb.DefineDefaultConstructor(MethodAttributes.Public);
MethodBuilder method = tb.DefineMethod(mymethod,
MethodAttributes.Static | MethodAttributes.Public, tb,
Type.EmptyTypes); ILGenerator ig = method.GetILGenerator();
ig.DeclareLocal(tb); ig.Emit(OpCodes.Newobj, cb);
ig.Emit(OpCodes.Stloc_0); ig.Emit(OpCodes.Ldloc_0);
ig.Emit(OpCodes.Ret); tb.CreateType(); ab.Save(myassembly.dll);
Although using a generic type definition directly makes little sense,
neither makes using tb.MakeGenericType(tb.GetGenericArguments()) much
more sense, since you still can use the latter in a context that has
fewer generic arguments.
Kornél
Jeroen Frijters wrote:
Hi Kornél,
I've fixed most of the things that your patch addressed. I also
removed support for the TypeForwardedToAttribute and
DefaultParameterValueAttribute pseudo custom attributes (because I
realized that supporting them is incompatible with my goal to be a
drop in replacement for System.Reflection.Emit).
One thing I didn't change is WriteGenericSignature, because your
change didn't make sense to me. It should not be possible that this
method gets called with a generic type definition.
I have not yet added anything additional for version info unmanaged
resources. I need to do more thinking about this.
Regards,
Jeroen
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, There simply is no special case for building mscorlib.dll. There is a /nostdlib option however that enables features required for building mscorlib.dll. I would recommend SetMscorlib over LoadMscorlib because that would not restrict how you can create or load mscorlib.dll. Kornél Jeroen Frijters wrote: I've just realized that DefineDynamicAssemblyImpl should not hardcode the name mscorlib since C# compiler is able to us any name when compiling with nostdlib. The hardcoded name bother me too, but then I couldn't think of any realistic scenario where you'd build an mscorlib with a different name. Do you have any examples? Also, how does gmcs know that it is compiling mscorlib? BTW, the solution I would prefer would be to add DefineMscorlib() (taking the same parameters as DefineDynamicAssembly). Regards, Jeroen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Please see the attached patch.
I belive that this is actually an easier and cleaner solution than the
current one.
You can use Load, LoadFile, DefineDynamicAssembly, etc. to load
mscorlib.dll.
Kornél
Jeroen Frijters write:
I would recommend SetMscorlib over LoadMscorlib because that would not
restrict how you can create or load mscorlib.dll.
That feels like painting yourself into a corner to me. Using SetMscorlib would
require modifying DefineDynamicAssembly in a way that would make it hard to
remain compatible with .NET reflection.
Please consider that from my point of view, gmcs building mscorlib is a
complete corner case, not what the API should be optimized for.
Regards,
Jeroen
Index: Universe.cs
===
RCS file: /cvsroot/ikvm/ikvm/reflect/Universe.cs,v
retrieving revision 1.13
diff -u -r1.13 Universe.cs
--- Universe.cs 7 May 2010 16:35:47 - 1.13
+++ Universe.cs 8 May 2010 12:37:44 -
@@ -389,7 +389,7 @@
public bool HasMscorlib
{
- get { return importedTypes.Count != 0 ||
assembliesByName.Count != 0; }
+ get { return
assembliesByName.ContainsKey(typeof(object).Assembly.FullName); }
}
public event ResolveEventHandler AssemblyResolve
@@ -398,19 +398,20 @@
remove { resolvers.Remove(value); }
}
- public void LoadMscorlib(string path)
- {
- if (HasMscorlib)
+ public void SetMscorlib(Assembly asm)
+ {
+ string mscorlibName = typeof(object).Assembly.FullName;
+ Assembly mscorlibAssembly;
+ if (assembliesByName.TryGetValue(mscorlibName, out
mscorlibAssembly) mscorlibAssembly != asm)
{
throw new InvalidOperationException();
- }
- Assembly asm = LoadFile(path);
- if (asm.FullName != typeof(object).Assembly.FullName)
+ }
+ if (asm.FullName != mscorlibName)
{
// make the current mscorlib full name an alias
for the specified mscorlib,
// this ensures that all the runtime built in
type are resolved against the
- // specified mscorlib.
-
assembliesByName.Add(typeof(object).Assembly.FullName, asm);
+ // specified mscorlib.
+ assembliesByName.Add(mscorlibName, asm);
}
}
@@ -680,14 +681,9 @@
private AssemblyBuilder DefineDynamicAssemblyImpl(AssemblyName
name, AssemblyBuilderAccess access, string dir, PermissionSet
requiredPermissions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions)
{
- bool mscorlib = !HasMscorlib name.Name == mscorlib;
AssemblyBuilder asm = new AssemblyBuilder(this, name,
dir, requiredPermissions, optionalPermissions, refusedPermissions);
assembliesByName.Add(GetAssemblyIdentityName(asm.GetName()), asm);
assemblies.Add(asm);
- if (mscorlib)
- {
-
assembliesByName[typeof(object).Assembly.FullName] = asm;
- }
return asm;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi,
Thank you for applying/enhacing the patches. I'll check it out.
This code will work on both of Mono and MS.NET, but will fail without
the WriteGenericSignature patch:
AssemblyBuilder ab = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(myassembly), AssemblyBuilderAccess.Save);
ModuleBuilder mb = ab.DefineDynamicModule(myassembly, myassembly.dll);
TypeBuilder tb = mb.DefineType(mytype, TypeAttributes.Public);
tb.DefineGenericParameters(new string[] { T, U });
ConstructorBuilder cb =
tb.DefineDefaultConstructor(MethodAttributes.Public);
MethodBuilder method = tb.DefineMethod(mymethod,
MethodAttributes.Static | MethodAttributes.Public, tb, Type.EmptyTypes);
ILGenerator ig = method.GetILGenerator();
ig.DeclareLocal(tb);
ig.Emit(OpCodes.Newobj, cb);
ig.Emit(OpCodes.Stloc_0);
ig.Emit(OpCodes.Ldloc_0);
ig.Emit(OpCodes.Ret);
tb.CreateType();
ab.Save(myassembly.dll);
Although using a generic type definition directly makes little sense,
neither makes using tb.MakeGenericType(tb.GetGenericArguments()) much
more sense, since you still can use the latter in a context that has
fewer generic arguments.
Kornél
Jeroen Frijters wrote:
Hi Kornél,
I've fixed most of the things that your patch addressed. I also removed
support for the TypeForwardedToAttribute and DefaultParameterValueAttribute
pseudo custom attributes (because I realized that supporting them is
incompatible with my goal to be a drop in replacement for
System.Reflection.Emit).
One thing I didn't change is WriteGenericSignature, because your change
didn't make sense to me. It should not be possible that this method gets
called with a generic type definition.
I have not yet added anything additional for version info unmanaged
resources. I need to do more thinking about this.
Regards,
Jeroen
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi Jeroen,
Thank you for the fixes.
New problems after the modifications:
SetCustomAttribute now fails for example for DllImportAttribute when
building mscorlib.dll because ReadFixedArg calls GetEnumUnderlyingType
and CheckBaked fails.
AssemblyKeyFileAttribute and AssemblyKeyNameAttribute should not be
considered pseudo custom attributes because even MS csc.exe emits those
attributes and Debug.Assert fails.
Also note that according to my tests AssemblyHashAlgorithm.None is
changed to AssemblyHashAlgorithm.SHA1 when setting the assembly name
because GetName returns AssemblyHashAlgorithm.SHA1 (rather than only
when calling Save).
Kornél
Jeroen Frijters wrote:
Hi Kornél,
This has now been fixed.
Thanks,
Jeroen
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Friday, May 07, 2010 10:33 AM
To: Jeroen Frijters
Cc: Marek Safar; mono-devel; Miguel de Icaza
Subject: Re: Porting mcs to IKVM.Reflection
Hi,
Thank you for applying/enhacing the patches. I'll check it out.
This code will work on both of Mono and MS.NET, but will fail without
the WriteGenericSignature patch:
AssemblyBuilder ab = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(myassembly), AssemblyBuilderAccess.Save);
ModuleBuilder mb = ab.DefineDynamicModule(myassembly,
myassembly.dll);
TypeBuilder tb = mb.DefineType(mytype, TypeAttributes.Public);
tb.DefineGenericParameters(new string[] { T, U });
ConstructorBuilder cb =
tb.DefineDefaultConstructor(MethodAttributes.Public);
MethodBuilder method = tb.DefineMethod(mymethod,
MethodAttributes.Static | MethodAttributes.Public, tb, Type.EmptyTypes);
ILGenerator ig = method.GetILGenerator();
ig.DeclareLocal(tb);
ig.Emit(OpCodes.Newobj, cb);
ig.Emit(OpCodes.Stloc_0);
ig.Emit(OpCodes.Ldloc_0);
ig.Emit(OpCodes.Ret);
tb.CreateType();
ab.Save(myassembly.dll);
Although using a generic type definition directly makes little sense,
neither makes using tb.MakeGenericType(tb.GetGenericArguments()) much
more sense, since you still can use the latter in a context that has
fewer generic arguments.
Kornél
Jeroen Frijters wrote:
Hi Kornél,
I've fixed most of the things that your patch addressed. I also
removed support for the TypeForwardedToAttribute and
DefaultParameterValueAttribute pseudo custom attributes (because I
realized that supporting them is incompatible with my goal to be a drop
in replacement for System.Reflection.Emit).
One thing I didn't change is WriteGenericSignature, because your
change didn't make sense to me. It should not be possible that this
method gets called with a generic type definition.
I have not yet added anything additional for version info unmanaged
resources. I need to do more thinking about this.
Regards,
Jeroen
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, Can you please tell when are MakeExpression methods used and whether are they required for code generation by mcs? The problem is that SLE MakeExpression methods require System.Reflection types. I was unable to find out when are MakeExpression methods used so I cannot come up with a solution. Thank you. Kornél Kornél Pál wrote: Hi, Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a try to port mcs to IKVM.Reflection. I addition to being able to have a single binary, mcs could run on MS.NET and we would not have to break MS.NET compatibility in System.Reflection. I've attached some work in progress patches both for mcs and IKVM.Reflection. I was impressed by the result that mcs is able to bootstrap itself, compile mscorlib.dll and its other requirements, and the resulting mcs is able to compile a bunch of Mono assemblies. Missing features: - security attributes - embedded resources - .netmodule support - debug info Also note that I was unable to figure out what MakeExpression methods are supposed to do but I had to disable them because they need System.Reflection types. mcs pathes are licensed under the MIT/X11 license. IKVM.Reflection patches are licensed under the zlib license. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi Marek, Thank you for your reply. I'm trying to keep differences minimal, and I have no intention to drop System.Reflection support: #if IKVM_REF_EMIT using IKVM.Reflection; using IKVM.Reflection.Emit; using Type = IKVM.Reflection.Type; #else using System.Reflection; using System.Reflection.Emit; #endif My other modifications are around hacks for overcoming limitations of System.Reflection[.Emit] that make mcs depend on the Mono runtime, so actually I'm just trying to make the code hack free. My understanding is that basically we only have two compilers: - static: mcs.exe, gmcs.exe, smcs.exe, dmcs.exe (for each profile) - dynamic: Mono.CSharp.dll, that is used by Microsoft.CSharp.dll and csharp.exe As I see (based on your explanation) only the dynamic (as in the above list) compiler is using MakeExpression methods that will have to use System.Reflection anyway because they generate code that can be executed without saving an assembly first that requires runtime support. Because of conditional compilation and minimal code changes, having support for both SRE implementations - in my opinion - is not (significantly) increasing code maintenance requirements. If the above assumptations are correct then all the MakeExpression methods can safely be #if-ed out when building the static compilers and thus there are no features that cannot be implemented by using IKVM.Reflection. Is this correct? Kornél Marek Safar wrote: Hi Kornél Can you please tell when are MakeExpression methods used and whether are they required for code generation by mcs? The problem is that SLE MakeExpression methods require System.Reflection types. I was unable to find out when are MakeExpression methods used so I cannot come up with a solution. MakeExpression is used by dynamic C# compiler for dynamic code generation. MakeExpression uses System.Type type-system and always will, therefore gmcs must work with System.Type. You can browse /mcs/class/Microsoft.CSharp for more details. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, I'm still in the stage of getting the things work, so I haven't really care about performance yet, but I'll give you some numbers once I consider the patch complete. Also note that IKVM.Reflection support is implemented using conditional compilation directives, so adding support for IKVM.Reflection does not have to mean stwitching to IKVM.Reflection. Kornél Marek Safar wrote: Hello Kornél, Thanks for the proof of concept of using System.Reflection.Emit with latest gmcs. I'll look into this more deeply when I iron out all regressions caused by the big change. It would be interesting to get some numbers out, I don't believe there should be much difference between SR(E) and IKVM but one never know. If you are going to do some testing use any real user assembly (not mscorlib), for instance System.Web or MD. Regards, Marek mcs creates an assembly, then creates types, and only after that is processing the custom attributes. This is how attributes and even assembly name (not the name part) can change after definition. Although there are some other self referencing cases, this order of creation/definition is required especially when building mscorlib.dll. At least some cases of these requirements could be eliminated by doing dependency analysis but there is no use to introduce extra complexity when the solution is very simple. All of these functions are implemented as hacks in Mono's System.Reflection.Emit. Blob encoded pseudo custom attributes are supported by Mono. I've added decoding because they weren't ignored, exceptions were thrown instead. I think that the only problem is that I've removed the exception when emitting backward jumps but since things were working so far, I haven't tried to resove that issue yet. (This is a work-in-progress state.) Unlike Java, C# has support for backward jumps, so does System.Reflection.Emit so support for that will have to be implemented. Some notes on IKVM.Reflection: First of all, thank you very much for creating it, since it's very unique. Based on your questions I belive that you are trying to remain compatible with MS.NET. This good, because both IKVM and mcs has a dynamic mode that is generating code for direct execution that requires System.Reflection.Emit. And to some extent enables IKVM.Reflection to be a drop-in replacement for System.Reflection.Emit on runtimes that have no built-in support. I on the other hand belive that removing arbitrary limitations of System.Reflection.Emit (like preventing access to TypeBuilder's member-builders), and adding missing functionality would make sense. Mono.Cecil is a great tool but it targets tools operating on metadata rather and is too abstract and complex for compilers. It also has a larger memory footprint. So I belive that there is a need for IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit as well. I also like the concept of having a Universe since that makes possible to have multiple compiler instances in the same AppDomain. I belive that pseudo custom attributes and unmanaged resource generation does not fit well to the concept of System.Reflection.Emit. I would rather remove support for both of these and introduce __methods for setting metadata that currently is built from pseudo custom attributes. Unmanaged resource generation could be automated (and customized) by using a dedicated class. This would be much faster than encoding (either binary or just the constructor arguments) and then decoding pseudo custom attributes. I also belive that CustomAttributeData should not be used as a provider, __GetCustomAttributes (non-standard since is returning constructor arguments rather than class instance) methods should be added to reflection classes. An ICustomAttributeProvider interface (with IsDefined and __GetCustomAttributes methods) would be very useful as well. As a conclusion I would be happy to see features (that make sense) in IKVM.Reflection.Emit that are not present in System.Reflection.Emit. Kornél Jeroen Frijters wrote: Hi, Thanks for the IKVM.Reflection patches. I have a few questions about some of the changes. - Why are the various _SetAttributes methods and the AssemblyBuilder.__SetName() methods necessary? - Do you really need blob encoded pseudo custom attributes in the version info? I intentionally don't suppor that (and also include the attributes as regular attributes) to be compatible with .NET - Why are all the stack height asserts commented out in ILGenerator, do you think they are wrong? Thanks, Jeroen -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Tuesday, May 04, 2010 2:03 PM To: mono-devel Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters Subject: Porting mcs to IKVM.Reflection Hi, Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a try to port mcs
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, Jeroen Frijters wrote: Kornél Pál wrote: mcs creates an assembly, then creates types, and only after that is processing the custom attributes. This is how attributes and even assembly name (not the name part) can change after definition. Although there are some other self referencing cases, this order of creation/definition is required especially when building mscorlib.dll. OK, that makes sense. I skipped custom attributes in my mcs IKVM.Reflection hack, so that may account for not running into that. I don't really like AssemblyBuilder.__SetName(), however. How about adding __SetVersion(), __SetCulture() and __SetKeyPair()? That would be a better idea. Updating Universe.assembliesByName also would make sense. Unlike Java, C# has support for backward jumps, so does System.Reflection.Emit so support for that will have to be implemented. The backwards branch constraint is an ECMA CIL restriction. The Microsoft CLR supports code that violates it, but years ago when I first found out about this it was because ikvm generated code that violated it and Mono didn't support that. So, I don't think it is necessary to support this (as it isn't valid ECMA CIL anyway). If mcs generates code that triggers this exception, then it is a bug in ILGenerator, or a bug in mcs. Right, your check implements the ECMA requirements. There must be some other problem then... I'll analyze that later. Based on your questions I belive that you are trying to remain compatible with MS.NET. Yes. However, I'm all for adding extra functionality (either by __ methods or by having ___ settings to enable/disable specific behavior). Using global (or instance-wide) flags may not be that good. Having __methods that behave differently or have arguments (boolean or enum) that either enable MS.NET compatible behavior or some other custom behavior should be considered as well. In the latter case MS.NET compatible methods could simply call the __ methods with parameters that ensure MS.NET compatible behavior. I belive that pseudo custom attributes and unmanaged resource generation does not fit well to the concept of System.Reflection.Emit. I kind of agree. I will add a mode to disable them and add specific __ methods to do the equivalent. That would be awesome. I also belive that CustomAttributeData should not be used as a provider, __GetCustomAttributes (non-standard since is returning constructor arguments rather than class instance) methods should be added to reflection classes. An ICustomAttributeProvider interface (with IsDefined and __GetCustomAttributes methods) would be very useful as well. Agreed. Marek Safar wrote: I am not sure I follow here, CustomAttributeData exists because they behave very differently to ICustomAttributeProvider. Why would you unify them? CustomAttributeData is not just the data store, it's methods are the only public API to obtain custom attributes (using the provider design pattern). ICustomAttributeProvider name can be retained because IsDefined is totally compatible while using __GetCustomAttributes marks that it is non-standard. I belive that pseudo custom attributes and unmanaged resource generation does not fit well to the concept of System.Reflection.Emit. I kind of agree. I will add a mode to disable them and add specific __ methods to do the equivalent. I am not that convinced, everyone writing non-trivial app will have to deal with them in some way. My bad. I should have say that unmanaged resource generation does not well fit to the concept of AssemblyBuilder. There should be a better unmanaged resource generation class that fits System.Reflection.Emit better. The best example is that Mono's SRE has hack for unmanaged resource generation in compiler context mode. After reading both of your responses I belive that pseudo custom attributes is not that harmful but there should be SetCustomAttribute methods (on each SRE class that supports custom attributes) that treats pseudo custom attributes like a compiler does, and a variant that just emits all the attributes. Maybe there should be three modes: - processing all pseudo custom attributes - emitting all of them as custom attributes - MS.NET compatible Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting mcs to IKVM.Reflection
Hi, mcs creates an assembly, then creates types, and only after that is processing the custom attributes. This is how attributes and even assembly name (not the name part) can change after definition. Although there are some other self referencing cases, this order of creation/definition is required especially when building mscorlib.dll. At least some cases of these requirements could be eliminated by doing dependency analysis but there is no use to introduce extra complexity when the solution is very simple. All of these functions are implemented as hacks in Mono's System.Reflection.Emit. Blob encoded pseudo custom attributes are supported by Mono. I've added decoding because they weren't ignored, exceptions were thrown instead. I think that the only problem is that I've removed the exception when emitting backward jumps but since things were working so far, I haven't tried to resove that issue yet. (This is a work-in-progress state.) Unlike Java, C# has support for backward jumps, so does System.Reflection.Emit so support for that will have to be implemented. Some notes on IKVM.Reflection: First of all, thank you very much for creating it, since it's very unique. Based on your questions I belive that you are trying to remain compatible with MS.NET. This good, because both IKVM and mcs has a dynamic mode that is generating code for direct execution that requires System.Reflection.Emit. And to some extent enables IKVM.Reflection to be a drop-in replacement for System.Reflection.Emit on runtimes that have no built-in support. I on the other hand belive that removing arbitrary limitations of System.Reflection.Emit (like preventing access to TypeBuilder's member-builders), and adding missing functionality would make sense. Mono.Cecil is a great tool but it targets tools operating on metadata rather and is too abstract and complex for compilers. It also has a larger memory footprint. So I belive that there is a need for IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit as well. I also like the concept of having a Universe since that makes possible to have multiple compiler instances in the same AppDomain. I belive that pseudo custom attributes and unmanaged resource generation does not fit well to the concept of System.Reflection.Emit. I would rather remove support for both of these and introduce __methods for setting metadata that currently is built from pseudo custom attributes. Unmanaged resource generation could be automated (and customized) by using a dedicated class. This would be much faster than encoding (either binary or just the constructor arguments) and then decoding pseudo custom attributes. I also belive that CustomAttributeData should not be used as a provider, __GetCustomAttributes (non-standard since is returning constructor arguments rather than class instance) methods should be added to reflection classes. An ICustomAttributeProvider interface (with IsDefined and __GetCustomAttributes methods) would be very useful as well. As a conclusion I would be happy to see features (that make sense) in IKVM.Reflection.Emit that are not present in System.Reflection.Emit. Kornél Jeroen Frijters wrote: Hi, Thanks for the IKVM.Reflection patches. I have a few questions about some of the changes. - Why are the various _SetAttributes methods and the AssemblyBuilder.__SetName() methods necessary? - Do you really need blob encoded pseudo custom attributes in the version info? I intentionally don't suppor that (and also include the attributes as regular attributes) to be compatible with .NET - Why are all the stack height asserts commented out in ILGenerator, do you think they are wrong? Thanks, Jeroen -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Tuesday, May 04, 2010 2:03 PM To: mono-devel Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters Subject: Porting mcs to IKVM.Reflection Hi, Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a try to port mcs to IKVM.Reflection. I addition to being able to have a single binary, mcs could run on MS.NET and we would not have to break MS.NET compatibility in System.Reflection. I've attached some work in progress patches both for mcs and IKVM.Reflection. I was impressed by the result that mcs is able to bootstrap itself, compile mscorlib.dll and its other requirements, and the resulting mcs is able to compile a bunch of Mono assemblies. Missing features: - security attributes - embedded resources - .netmodule support - debug info Also note that I was unable to figure out what MakeExpression methods are supposed to do but I had to disable them because they need System.Reflection types. mcs pathes are licensed under the MIT/X11 license. IKVM.Reflection patches are licensed under the zlib license. Kornél ___ Mono-devel-list mailing list Mono-devel-list
Re: [Mono-dev] [PATCH] Fix CompareExchange inlining for I8
Hi,
Fixed in SVN HEAD r155039 and mono-2-6 r155040.
Kornél
Miguel de Icaza wrote:
Hello,
Would you mind backporting this to the 2-6 branch as well?
2010/4/7 Kornél Pál kornel...@gmail.com:
Hi,
Currently CompareExchange for I8 is never inlined because of a typo.
Note that other Interlocked methods use SIZEOF_REGISTER while this use the
size of pointer and I don't know which one of these is the right one since
both registers and pointers are involved.
Please review the patch.
Kornél
Index: method-to-ir.c
===
--- method-to-ir.c (revision 154913)
+++ method-to-ir.c (working copy)
@@ -4252,7 +4252,7 @@
size = 4;
else if (is_ref || fsig-params [1]-type ==
MONO_TYPE_I)
size = sizeof (gpointer);
- else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I4)
+ else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I8)
size = 8;
if (size == 4) {
MONO_INST_NEW (cfg, ins, OP_ATOMIC_CAS_I4);
___
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] Fix CompareExchange inlining for I8
Hi,
Currently CompareExchange for I8 is never inlined because of a typo.
Note that other Interlocked methods use SIZEOF_REGISTER while this use
the size of pointer and I don't know which one of these is the right one
since both registers and pointers are involved.
Please review the patch.
Kornél
Index: method-to-ir.c
===
--- method-to-ir.c (revision 154913)
+++ method-to-ir.c (working copy)
@@ -4252,7 +4252,7 @@
size = 4;
else if (is_ref || fsig-params [1]-type ==
MONO_TYPE_I)
size = sizeof (gpointer);
- else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I4)
+ else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I8)
size = 8;
if (size == 4) {
MONO_INST_NEW (cfg, ins, OP_ATOMIC_CAS_I4);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] How to fix StrLike bug in 2.4
Hi,
StrLike implementation seems to be very inefficient and is also
defective because does not escape characters that have special meaning
in regular expressions that are used as the underlaying implementation.
I would suggest you to use regular expressions because those are more
properly supported.
Kornél
Andrus wrote:
Code below produes invalid result (False) in 2.4 and 2.6
How to fix it so it runs properly in 2.4.2 ?
Andrus.
using System;
using System.IO;
class Program
{
static void Main()
{
string source = @SELECT COALESCE(kartotee.Aj,0) AS Aj,
kartotee.Doktyyp AS Doktyyp, COALESCE(kartotee.Dokumnr,0) AS Dokumnr,
COALESCE(kartotee.Hind,0) AS Hind, COALESCE(rid.Inpdoktyyp,'') AS
Inpdoktyyp,
COALESCE(rid.Inpdokumnr,0) AS Inpdokumnr, COALESCE(kartotee.Kogpak,0) AS
Kogpak, COALESCE(kartotee.Kogus,0) AS Kogus, kartotee.Kuupaev AS Kuupaev,
COALESCE(kartotee.Partii,'') AS Partii, COALESCE(kartotee.Skaubasumm,0) AS
Skaubasumm, COALESCE(kartotee.St,0) AS St, COALESCE(kartotee.Toode,'') AS
Toode, COALESCE(kartotee.Vkaubasumm,0) AS Vkaubasumm,
COALESCE(kartotee.Vm,0)
AS Vm, COALESCE(kartotee.Yksus,'') AS Yksus, COALESCE(Artliik.Arttyyp,'') AS
ArtliikArttyyp, COALESCE(Dok.Kellaaeg,'') AS DokKellaaeg, Dok.Kuupaev AS
DokKuupaev, COALESCE(Dok.Raha,'') AS DokRaha, COALESCE(Toode.Jaehind,0) AS
ToodeJaehind, COALESCE(Toode.Nimetus,'') AS ToodeNimetus,
COALESCE(Toode.Yhik,'') AS ToodeYhik
FROM ({0}) kartotee
JOIN prpalk ON true
JOIN toode ON kartotee.toode=toode.toode
LEFT JOIN artliik USING(grupp,liik)
LEFT JOIN rid ON rid.id=kartotee.id
LEFT JOIN dok ON kartotee.dokumnr=dok.dokumnr
LEFT JOIN klient ON dok.klient=klient.kood
;
string pattern = @SELECT*FROM ({0}) *;
var res = Microsoft.VisualBasic.CompilerServices.StringType.StrLike(
source, pattern,
Microsoft.VisualBasic.CompareMethod.Text);
Console.WriteLine(res.ToString());
Console.ReadLine();
}
}
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Issues with System.Random
You can use the OnDeserializedAttribute and NonSerializedAttribute attributes. Adrian Willenbücher wrote: Kornél Pál wrote: Also note that this patch seems to break serialization compatibility that might be a problem for some applications. That is indeed a problem. However, it should be sufficient to load the state and xor it with the default state if the serialized object is the old version. Is that possible? Best regards, Adrian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
Also note that this patch seems to break serialization compatibility
that might be a problem for some applications.
Kornél
Andreas Nahr wrote:
I won't comment on the algorithm itself (keep in mind that the existing one
already was replaced once with a better one which failed miserably in real
world apps, so had to be reverted).
Also a newsgroup as source doesn't sound reliable at all.
But your patch adds errors for exceptions (which were mostly correct
before). And the unit-tests are no unit-tests. They don't test the
implementation against the specification, they test the implementation
against the implementation which is useless. And moreover you removed ALL
Random() constructor tests which most likely are the only of relevance to
real-world applications.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Adrian
Willenbücher
Gesendet: Montag, 15. März 2010 23:33
An: mono-devel-list@lists.ximian.com
Betreff: [Mono-dev] Issues with System.Random
Hello,
I noticed that the implementation of System.Random has a couple of flaws:
1.) The algorithm for the random data fails miserably in some of the Diehard
tests (http://i.cs.hku.hk/~diehard/), even
if it is slightly changed in order to generate full 32-bit random values.
2.) It might return a negative value:
if (retVal 0) retVal += MBIG;
results in -1 for retVal == int.MinValue, which is forbidden.
3.) The use of floating-point arithmetic introduces numerical errors since
int.MaxValue is not a power of two (so
1.0/int.MaxValue is not representable without errors).
I reimplemented the class using the xorshift algorithm by George Marsaglia,
which he posted on comp.lang.c
(http://groups.google.com/group/comp.lang.c/browse_thread/thread/a9915080a44
24068/), and tested it with the Diehard
battery of tests (it passed); it avoids any FP arithmetic where it is not
needed.
The interface of the class is still pretty screwed up, but sadly we can't
change that.
I also completely rewrote the unit tests; they are stricter and more precise
now. The expected values were produced by
running the C-code given by George Marsaglia.
The patches for the two files can be found below.
Regards,
Adrian
Index: mcs/class/corlib/System/Random.cs
===
--- mcs/class/corlib/System/Random.cs (revision 153607)
+++ mcs/class/corlib/System/Random.cs (working copy)
@@ -4,12 +4,11 @@
// Authors:
// Bob Smith (b...@thestuff.net)
// Ben Maurer (bmau...@users.sourceforge.net)
+// Adrian Willenbücher (awillenbuec...@gmx.de)
//
// (C) 2001 Bob Smith. http://www.thestuff.net
// (C) 2003 Ben Maurer
//
-
-//
// Copyright (C) 2004 Novell, Inc (http://www.novell.com)
//
// Permission is hereby granted, free of charge, to any person obtaining
@@ -39,104 +38,98 @@
[ComVisible (true)]
public class Random
{
- const int MBIG = int.MaxValue;
- const int MSEED = 161803398;
+ private uint [] state = new uint [5];
- int inext, inextp;
- int [] SeedArray = new int [56];
-
- public Random ()
- : this (Environment.TickCount)
+ public Random () : this(Environment.TickCount)
{
}
public Random (int Seed)
{
- int ii;
- int mj, mk;
-
- // Numerical Recipes in C online @
http://www.library.cornell.edu/nr/bookcpdf/c7-1.pdf
- mj = MSEED - Math.Abs (Seed);
- SeedArray [55] = mj;
- mk = 1;
- for (int i = 1; i 55; i++) { // [1, 55] is
special (Knuth)
- ii = (21 * i) % 55;
- SeedArray [ii] = mk;
- mk = mj - mk;
- if (mk 0)
- mk += MBIG;
- mj = SeedArray [ii];
- }
- for (int k = 1; k 5; k++) {
- for (int i = 1; i 56; i++) {
- SeedArray [i] -= SeedArray [1 + (i +
30) % 55];
- if (SeedArray [i] 0)
- SeedArray [i] += MBIG;
- }
- }
- inext = 0;
- inextp = 31;
+ state [0] = 123456789 ^ (uint)Seed;
+ state [1] = 362436069;
+ state [2] = 521288629;
+ state [3] = 88675123;
+ state [4] = 886756453;
}
- protected
Re: [Mono-dev] Where is trampoline x86 pseudo code documented?
Hi,
I wouldn't say that this is pseudo-code. This is more like using a code
generator like using System.Reflection.Emit.ILGenerator for managed code.
Most of these instruction emitters are just preprocessor macros located
in mono/arch/x86/x86-codegen.h.
I believe that the names are quite intuitive but if you need to know the
exact instructions used just have a look at the above header file.
Kornél
cpMon wrote:
Is there a document that describes the x86 pseudo code your JIT engine uses.
For example, it would be a lot easier for me to find bugs for you if I
didn't have to reverse-engineer things such as:
Thanks,
Cal Page
if ( 0 mono_thread_get_tls_offset () != -1) {
/* MonoObject* obj is in EAX */
/* is obj null? */
x86_test_reg_reg (buf, X86_EAX, X86_EAX);
/* if yes, jump to actual trampoline */
jump_obj_null = buf;
x86_branch8 (buf, X86_CC_Z, -1, 1);
/* load obj-synchronization to ECX */
x86_mov_reg_membase (buf, X86_ECX, X86_EAX, G_STRUCT_OFFSET
(MonoObject, synchronisation), 4);
/* is synchronization null? */
x86_test_reg_reg (buf, X86_ECX, X86_ECX);
/* if not, jump to next case */
jump_next = buf;
x86_branch8 (buf, X86_CC_NZ, -1, 1);
/* if yes, just return */
x86_ret (buf);
/* next case: synchronization is not null */
x86_patch (jump_next, buf);
/* load MonoThread* into EDX */
buf = mono_x86_emit_tls_get (buf, X86_EDX,
mono_thread_get_tls_offset ());
/* load TID into EDX */
x86_mov_reg_membase (buf, X86_EDX, X86_EDX, G_STRUCT_OFFSET
(MonoThread, tid), 4);
/* is synchronization-owner == TID */
x86_alu_membase_reg (buf, X86_CMP, X86_ECX, owner_offset,
X86_EDX);
/* if yes, jump to next case */
jump_next = buf;
x86_branch8 (buf, X86_CC_Z, -1, 1);
/* if not, just return */
x86_ret (buf);
/* next case: synchronization-owner == TID */
759,2-16 92%
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Thank you. Marek Safar wrote: Patch applied Thanks ChangeLog: Don't make compiler generated classes sealed by default. Emit and close top level compiler generated classes as well. ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the default GetHashCode implementation based. (Also note that some SRE classes haven no support for GetHashCode in MS.NET.) Please review the patch. Thanks. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hi Marek, Although currently only a single compiler generated class benefits from both of these modifications I don't see any drawbacks and in my opinion the changes result in a more properly designed compiler generated class infrastructure. I am not sure what does more properly designed compiler generated class infrastructure mean but removing sealed from other generated classes it's not. The fix should be to add a new overload to avoid clearing the sealed flag. Since the constructor accepts a Modifiers mod parameter adding another (for example bool) parameter that would affect the Modifiers parameter sounds too complicated to me. On more properly designed I mean that I belive that a class being comipler generated doesn't imply that it also has to be sealed, furthermore it also can be either sealed or static, and there is no need for enforcing any of them because the constructor accepts Modifiers. (Similarly it does not enforce any visibility flags either.) In my opinion adding Modifiers.COMPILER_GENERATED on the other hand is the expected behavior. CompilerGeneratedClass currently has three child classes: AnonymousMethodStorey: Currently relies on Modifiers.SEALED being added by the base class constructor and modified to pass Modifiers.SEALED to the base constructor in the patch. AnonymousTypeClass: Already passes Modifiers.SEALED to the base constructor. DynamicExpressionStatement.StaticDataClass: Passes Modifiers.STATIC to the base constructor and without the patch has to remove Modifiers.SEALED in its constructor body Kornel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hi Marek, Emit and close top level compiler generated classes as well. They are already closed. Most of the compiler generated classes are nested types and those are closed. On the other hand DynamicExpressionStatement.StaticDataClass in dynamic.cs is a top level compiler generated class. Currently it is closed by using RootContext.RegisterCompilerGeneratedType that is very ugly hack because that is closing the TypeBuilder rather than the compiler generated class instance that skips the whole infrastructure. In my opinion RootContext.RegisterCompilerGeneratedType is intended for compiler generated TypeBuilders that have no higher level representation that is not the case for compiler generated classes. Don't make compiler generated classes sealed by default. What is benefit of not doing that? This is also related to the same class because that was explicitly removing the sealed modifier to enable the static modifier. Although currently only a single compiler generated class benefits from both of these modifications I don't see any drawbacks and in my opinion the changes result in a more properly designed compiler generated class infrastructure. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Attached the same patch with coding style fixed.
Kornél Pál wrote:
Hi Marek,
Emit and close top level compiler generated classes as well.
They are already closed.
Most of the compiler generated classes are nested types and those are
closed.
On the other hand DynamicExpressionStatement.StaticDataClass in
dynamic.cs is a top level compiler generated class.
Currently it is closed by using
RootContext.RegisterCompilerGeneratedType that is very ugly hack because
that is closing the TypeBuilder rather than the compiler generated
class instance that skips the whole infrastructure.
In my opinion RootContext.RegisterCompilerGeneratedType is intended for
compiler generated TypeBuilders that have no higher level representation
that is not the case for compiler generated classes.
Don't make compiler generated classes sealed by default.
What is benefit of not doing that?
This is also related to the same class because that was explicitly
removing the sealed modifier to enable the static modifier.
Although currently only a single compiler generated class benefits from
both of these modifications I don't see any drawbacks and in my opinion
the changes result in a more properly designed compiler generated class
infrastructure.
Kornél
Index: mcs/dynamic.cs
===
--- mcs/dynamic.cs (revision 152670)
+++ mcs/dynamic.cs (working copy)
@@ -202,7 +202,6 @@
new MemberName
(CompilerGeneratedClass.MakeName (null, c, DynamicSites, 0)),
Modifiers.INTERNAL | Modifiers.STATIC)
{
- ModFlags = ~Modifiers.SEALED;
}
}
@@ -264,9 +263,6 @@
RootContext.ToplevelTypes.AddCompilerGeneratedClass (global_site_container);
global_site_container.DefineType ();
global_site_container.Define ();
-// global_site_container.EmitType ();
-
- RootContext.RegisterCompilerGeneratedType
(global_site_container.TypeBuilder);
}
return global_site_container;
Index: mcs/anonymous.cs
===
--- mcs/anonymous.cs(revision 152670)
+++ mcs/anonymous.cs(working copy)
@@ -25,7 +25,7 @@
}
protected CompilerGeneratedClass (DeclSpace parent, MemberName
name, Modifiers mod)
- : base (parent.NamespaceEntry, parent, name, mod |
Modifiers.COMPILER_GENERATED | Modifiers.SEALED, null)
+ : base (parent.NamespaceEntry, parent, name, mod |
Modifiers.COMPILER_GENERATED, null)
{
}
@@ -141,7 +141,7 @@
public LocalTemporary Instance;
public AnonymousMethodStorey (Block block, TypeContainer
parent, MemberBase host, GenericMethod generic, string name)
- : base (parent, generic, MakeMemberName (host, name,
generic, block.StartLocation), Modifiers.PRIVATE)
+ : base (parent, generic, MakeMemberName (host, name,
generic, block.StartLocation), Modifiers.PRIVATE | Modifiers.SEALED)
{
Parent = parent;
OriginalSourceBlock = block;
Index: mcs/support.cs
===
--- mcs/support.cs (revision 152670)
+++ mcs/support.cs (working copy)
@@ -17,6 +17,7 @@
using System.Reflection.Emit;
using System.Globalization;
using System.Collections.Generic;
+using System.Runtime.CompilerServices;
namespace Mono.CSharp {
@@ -30,12 +31,12 @@
public bool Equals (T x, T y)
{
- return object.ReferenceEquals (x, y);
+ return (object) x == (object) y;
}
public int GetHashCode (T obj)
{
- return obj == null ? 0 : obj.GetHashCode ();
+ return RuntimeHelpers.GetHashCode (obj);
}
}
Index: mcs/rootcontext.cs
===
--- mcs/rootcontext.cs (revision 152670)
+++ mcs/rootcontext.cs (working copy)
@@ -267,6 +267,9 @@
foreach (Delegate d in root.Delegates)
d.CloseType ();
+ if (root.CompilerGeneratedClasses != null)
+ foreach (CompilerGeneratedClass c in
root.CompilerGeneratedClasses)
+ c.CloseType ();
//
// If we have a PrivateImplementationDetails class,
close
[Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.
Hi,
ChangeLog:
Don't make compiler generated classes sealed by default.
Emit and close top level compiler generated classes as well.
ReferenceEquality comparer: Use RuntimeHelpers.GetHashCode that is the
default GetHashCode implementation based. (Also note that some SRE
classes haven no support for GetHashCode in MS.NET.)
Please review the patch.
Thanks.
Kornél
Index: mcs/dynamic.cs
===
--- mcs/dynamic.cs (revision 152621)
+++ mcs/dynamic.cs (working copy)
@@ -202,7 +202,6 @@
new MemberName
(CompilerGeneratedClass.MakeName (null, c, DynamicSites, 0)),
Modifiers.INTERNAL | Modifiers.STATIC)
{
- ModFlags = ~Modifiers.SEALED;
}
}
@@ -264,9 +263,6 @@
RootContext.ToplevelTypes.AddCompilerGeneratedClass (global_site_container);
global_site_container.DefineType ();
global_site_container.Define ();
-// global_site_container.EmitType ();
-
- RootContext.RegisterCompilerGeneratedType
(global_site_container.TypeBuilder);
}
return global_site_container;
Index: mcs/anonymous.cs
===
--- mcs/anonymous.cs(revision 152621)
+++ mcs/anonymous.cs(working copy)
@@ -25,7 +25,7 @@
}
protected CompilerGeneratedClass (DeclSpace parent, MemberName
name, Modifiers mod)
- : base (parent.NamespaceEntry, parent, name, mod |
Modifiers.COMPILER_GENERATED | Modifiers.SEALED, null)
+ : base (parent.NamespaceEntry, parent, name, mod |
Modifiers.COMPILER_GENERATED, null)
{
}
@@ -141,7 +141,7 @@
public LocalTemporary Instance;
public AnonymousMethodStorey (Block block, TypeContainer
parent, MemberBase host, GenericMethod generic, string name)
- : base (parent, generic, MakeMemberName (host, name,
generic, block.StartLocation), Modifiers.PRIVATE)
+ : base (parent, generic, MakeMemberName (host, name,
generic, block.StartLocation), Modifiers.PRIVATE | Modifiers.SEALED)
{
Parent = parent;
OriginalSourceBlock = block;
Index: mcs/support.cs
===
--- mcs/support.cs (revision 152621)
+++ mcs/support.cs (working copy)
@@ -17,6 +17,7 @@
using System.Reflection.Emit;
using System.Globalization;
using System.Collections.Generic;
+using System.Runtime.CompilerServices;
namespace Mono.CSharp {
@@ -30,12 +31,12 @@
public bool Equals (T x, T y)
{
- return object.ReferenceEquals (x, y);
+ return (object) x == (object) y;
}
public int GetHashCode (T obj)
{
- return obj == null ? 0 : obj.GetHashCode ();
+ return RuntimeHelpers.GetHashCode (obj);
}
}
Index: mcs/rootcontext.cs
===
--- mcs/rootcontext.cs (revision 152621)
+++ mcs/rootcontext.cs (working copy)
@@ -267,6 +267,9 @@
foreach (Delegate d in root.Delegates)
d.CloseType ();
+ if (root.CompilerGeneratedClasses != null)
+ foreach (CompilerGeneratedClass c in
root.CompilerGeneratedClasses)
+ c.CloseType();
//
// If we have a PrivateImplementationDetails class,
close it
@@ -373,6 +376,10 @@
d.Emit ();
}
+ if (root.CompilerGeneratedClasses != null)
+ foreach (CompilerGeneratedClass c in
root.CompilerGeneratedClasses)
+ c.EmitType();
+
CodeGen.Assembly.Emit (root);
root.Emit ();
}
Index: mcs/class.cs
===
--- mcs/class.cs(revision 152621)
+++ mcs/class.cs(working copy)
@@ -583,6 +583,14 @@
return delegates;
}
}
+
+ public IListCompilerGeneratedClass CompilerGeneratedClasses
+ {
+ get
+ {
+
Re: [Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
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 alan.mcgov...@gmail.com
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 tom.phil...@logos.com
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
Re: [Mono-dev] BufferedStream.ReadByte and WriteByte are extremely inefficient
Hi, 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 tom.phil...@logos.com 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
Re: [Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Miguel de Icaza wrote: I am not sure why we would include in Mono two classes that are flagged as internal. How would a user even use this? Handlers are mostly used in Web.config and the ASP.NET runtime uses reflection that makes it able to instantiate non-public types. This way users may not even realize that they are using internal types. On the other hand if you want to hide or deny requests you can use just like HttpForbiddenHandler but you can have additional HTTP status codes and messages. Of course you could duplicate this functionality in your own classes but it's easier to use existing framework classes. I just realized that Microsoft documented HttpForbiddenHandler that is internal as well and is implemented in Mono: http://msdn.microsoft.com/en-us/library/ms404282.aspx Originally HttpForbiddenHandler was exposed only in Web.config. HttpNotFoundHandler existed in 1.x but was not exposed in Web.config until 2.0. So people most likely know that these types exist and the might use them. I actually wanted to use it when I found out that we haven't had it. HttpNotImplementedHandler is not used in Web.config and is most likely known by much less people but I found it in the prevously referenced book so I just implemented that as well to make the internal simple handler collection complete. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Marek Habersack wrote: HttpNotImplementedHandler is not used in Web.config and is most likely known by much less people but I found it in the prevously referenced book so I just implemented that as well to make the internal simple handler collection complete. I don't think we should include it just for the sake of it. If you want it in, that's fine, but you need to modify all the spots in System.Web code which throw 404 and make sure there are no regressions in exception/error handling because of that. Only then the type can be included. These handlers need no special treatment. ASP.NET runtime should be and according to my experiences is able to receive HttpExceptions with status codes from handlers/user code. Only 403 and 404 codes are treated specially, that means a more destrictive error page, but that should not make any distinction based on the origin of the exception, just the status code. No maintenance requirements come with these two handlers. They just should be treated just like any other external handler. Their sole purpose is to throw HttpExceptions with the respective status code. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
I've received no comments or approval please review and if you like it,
approve the patch.
Thanks.
Kornél
Kornél Pál wrote:
Hi,
These two internal types are present in all .NET Framework versions.
HttpNotFoundHandler is exposed by default Web.config in .NET Framework 2.0.
HttpNotImplementedHandler is documented in book Professional ASP.NET 2.0
Security, Membership, and Role Management, page 66:
http://books.google.com/books?id=Qt3TeJJkG5oC
Kornél
Index: mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
===
--- mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
(revision 0)
+++ mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
(revision 0)
@@ -0,0 +1,46 @@
+//
+// System.Web.HttpNotImplementedHandler.cs
+//
+// Author:
+// Kornél Pál http://www.kornelpal.com/
+//
+// Copyright (C) 2009 Kornél Pál
+//
+
+//
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// Software), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+//
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+namespace System.Web
+{
+ internal class HttpNotImplementedHandler : IHttpHandler
+ {
+ public void ProcessRequest (HttpContext context)
+ {
+ HttpRequest request = context.Request;
+
+ throw new HttpException (501, request.HttpMethod +
+ request.Path + is not implemented.);
+ }
+
+ public bool IsReusable {
+ get { return true; }
+ }
+ }
+}
Property changes on:
mcs\class\System.Web\System.Web\HttpNotImplementedHandler.cs
___
Name: svn:eol-style
+ native
Index: mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs
===
--- mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
+++ mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
@@ -0,0 +1,46 @@
+//
+// System.Web.HttpNotFoundHandler.cs
+//
+// Author:
+// Kornél Pál http://www.kornelpal.com/
+//
+// Copyright (C) 2009 Kornél Pál
+//
+
+//
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// Software), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+//
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+namespace System.Web
+{
+ internal class HttpNotFoundHandler : IHttpHandler
+ {
+ public void ProcessRequest (HttpContext context)
+ {
+ string path = context.Request.Path;
+
+ throw new HttpException (404, Path ' + path + ' was
not found., path);
+ }
+
+ public bool IsReusable {
+ get { return true; }
+ }
+ }
+}
Property changes on: mcs\class\System.Web\System.Web\HttpNotFoundHandler.cs
___
Name: svn:eol-style
+ native
Index: mcs/class/System.Web/System.Web20.csproj
[Mono-dev] [PATCH] Fix cygwin build by adding mswsock lib
Please see the attached patch that fixes cygwin build by adding mswsock lib. Please review and if you like it, approve the patch. Thanks. Kornél Index: mono/configure.in === --- mono/configure.in (revision 145149) +++ mono/configure.in (working copy) @@ -1610,6 +1610,7 @@ AC_DEFINE(HAVE_GETPROCESSID, 1, [Define if GetProcessId is available]) else jdk_headers_found=no + AC_CHECK_LIB(mswsock, main, LIBS=$LIBS -lmswsock, AC_ERROR(bad mingw install?)) AC_CHECK_LIB(ws2_32, main, LIBS=$LIBS -lws2_32, AC_ERROR(bad mingw install?)) AC_CHECK_LIB(psapi, main, LIBS=$LIBS -lpsapi, AC_ERROR(bad mingw install?)) AC_CHECK_LIB(ole32, main, LIBS=$LIBS -lole32, AC_ERROR(bad mingw install?)) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Enable dolt on cygwin
Please see the attached patch that enables dolt on cygwin. I have tested this and found no problems. Please review and if you like it, approve the patch. Thanks. Kornél Index: mono/acinclude.m4 === --- mono/acinclude.m4 (revision 145149) +++ mono/acinclude.m4 (working copy) @@ -26,6 +26,9 @@ |amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*|arm*-*-linux*|sparc*-*-linux*|mips*-*-linux*) pic_options='-fPIC' ;; +i?86-pc-cygwin*) +pic_options='-DDLL_EXPORT' +;; i?86-apple-darwin*) pic_options='-fno-common' ;; ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Use trampolines for vtable fixups (Windows)
Please see the attached patch that is a separated and improved version
of the prevously submitted patch.
ChangeLog draft:
mono_image_fixup_vtable is now called only when the image is loaded and
creates trampolines rather than pointers to wrapper functions.
A new trampoline type MONO_TRAMPOLINE_VTFIXUP is added that is created
by mono_image_fixup_vtable, and is replacing the pointer to the
trampoline with the result mono_marshal_get_vtfixup_ftnptr.
Please review and if you like it, approve the patch.
Thanks.
Kornél
Index: mono/mono/metadata/assembly.c
===
--- mono/mono/metadata/assembly.c (revision 145149)
+++ mono/mono/metadata/assembly.c (working copy)
@@ -1522,11 +1522,6 @@
loaded_assemblies = g_list_prepend (loaded_assemblies, ass);
mono_assemblies_unlock ();
-#ifdef PLATFORM_WIN32
- if (image-is_module_handle)
- mono_image_fixup_vtable (image);
-#endif
-
mono_assembly_invoke_load_hook (ass);
mono_profiler_assembly_loaded (ass, MONO_PROFILE_OK);
Index: mono/mono/metadata/coree.c
===
--- mono/mono/metadata/coree.c (revision 145149)
+++ mono/mono/metadata/coree.c (working copy)
@@ -106,20 +106,12 @@
}
}
- if (!image) {
- g_free (file_name);
+ g_free (file_name);
+
+ if (!image)
return FALSE;
- }
- /*
-* FIXME: Find a better way to call mono_image_fixup_vtable.
Only
-* loader trampolines should be used and assembly loading should
-* probably be delayed until the first call to an exported
function.
-*/
- if (image-tables [MONO_TABLE_ASSEMBLY].rows
((MonoCLIImageInfo*) image-image_info)-cli_cli_header.ch_vtable_fixups.rva)
- assembly = mono_assembly_open (file_name, NULL);
-
- g_free (file_name);
+ mono_image_fixup_vtable (image);
break;
case DLL_PROCESS_DETACH:
if (lpReserved != NULL)
@@ -198,6 +190,8 @@
argv [i] = g_utf16_to_utf8 (argvw [i], -1, NULL, NULL, NULL);
LocalFree (argvw);
+ mono_image_fixup_vtable (image);
+
mono_runtime_run_main (method, argc, argv, NULL);
mono_thread_manage ();
@@ -919,8 +913,10 @@
void
mono_fixup_exe_image (MonoImage* image)
{
- if (!init_from_coree image image-is_module_handle)
+ if (!init_from_coree image image-is_module_handle) {
MonoFixupExe ((HMODULE) image-raw_data);
+ mono_image_fixup_vtable (image);
+ }
}
#endif /* PLATFORM_WIN32 */
Index: mono/mono/metadata/object.c
===
--- mono/mono/metadata/object.c (revision 145149)
+++ mono/mono/metadata/object.c (working copy)
@@ -470,10 +470,18 @@
return NULL;
}
+static gpointer
+default_vtfixup_trampoline (gpointer slot, MonoImage *image, guint32 token,
guint16 type)
+{
+ g_assert_not_reached ();
+ return NULL;
+}
+
static MonoTrampoline arch_create_jit_trampoline = default_trampoline;
static MonoJumpTrampoline arch_create_jump_trampoline =
default_jump_trampoline;
static MonoRemotingTrampoline arch_create_remoting_trampoline =
default_remoting_trampoline;
static MonoDelegateTrampoline arch_create_delegate_trampoline =
default_delegate_trampoline;
+static MonoVTFixupTrampoline arch_create_vtfixup_trampoline =
default_vtfixup_trampoline;
static MonoImtThunkBuilder imt_thunk_builder = NULL;
#define ARCH_USE_IMT (imt_thunk_builder != NULL)
#if (MONO_IMT_SIZE 32)
@@ -517,6 +525,12 @@
}
void
+mono_install_vtfixup_trampoline (MonoVTFixupTrampoline func)
+{
+ arch_create_vtfixup_trampoline = func? func: default_vtfixup_trampoline;
+}
+
+void
mono_install_imt_thunk_builder (MonoImtThunkBuilder func) {
imt_thunk_builder = func;
}
@@ -564,6 +578,12 @@
return arch_create_delegate_trampoline (klass);
}
+gpointer
+mono_runtime_create_vtfixup_trampoline (gpointer slot, MonoImage *image,
guint32 token, guint16 type)
+{
+ return arch_create_vtfixup_trampoline (slot, image, token, type);
+}
+
static MonoFreeMethodFunc default_mono_free_method = NULL;
/**
Index: mono/mono/metadata/class-internals.h
===
--- mono/mono/metadata/class-internals.h(revision 145149)
+++ mono/mono/metadata/class-internals.h(working copy)
@@ -803,6 +803,7 @@
typedef gpointer (*MonoJumpTrampoline) (MonoDomain *domain, MonoMethod
*method, gboolean add_sync_wrapper);
typedef gpointer (*MonoRemotingTrampoline) (MonoDomain *domain,
MonoMethod *method, MonoRemotingTarget target);
typedef gpointer
Re: [Mono-aspnet-list] FastCgi Mono Server and Apache
Hi, loopedcode wrote: /home/user1/bin/mono-fcgi There is no need to try to spawn an fcgi process every time. cgi-fcgi takes care of that if you use it according to http://www.mono-project.com/CGI # stdin is the socket handle exec env \ /usr/local/bin/fastcgi-mono-server2 \ /socket=unix:$SOCKET \ /root=/home/user1/www/aspnet \ /applications=/:/home/user1/www/aspnet \ /logfile=/home/user1/bin/mono-fcgi.log \ /loglevels=All \ 2 /home/user1/bin/mono-fcgi.err You have to use env -i and pass all your relevant environment variables explicitly because mono-fastcgi-server will otherwise fall back to CGI environment variables that most likely will cause you trouble. Also note that stdin is the socket handle is not the case in your case. If you let cgi-fcgi spawn your fcgi server when it's not available then cgi-fcgi will take care of socket creation as well. If you still have problems, please also send your Apache configuration. Kornél ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-dev] Mono hangs on shutdown when /dev/ttySx ports were opened.
Hi, Zoltan Varga wrote: The runtime tries to abort all threads and waits for them to terminate, so if a thread refuses to die for some reason, the runtime will hang. Its possible that the This hang has occurred or different reasons and was reported several times. Is there a specific reason that prevents us from terminating all the threads on exit? MS.NET simply kills all the threads and usually the finally blocks aren't even executed on exit. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] xsp2 and *nux question
Hi, Use xsp2 --nonstop Kornél Xu, Jiangyan wrote: Hello, I am using xsp2 as a lightweight server for my web application. I wanted to run it as a daemon process but when I use xsp2 the process immediately exits. I guess the problem here is that xsp2 reads 'Return' (Console.ReadLine()) as a signal to stop but when run as a daemon, the stdin gives the process EOF or something. Is there a way to get around this? Best, Jiangyan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] using coreclr in mono embedding sample project
Hi, I don't know how Silverlight works on Windows but it should be checked first. There are two possible solutions: 1) Load assemblies as byte arrays rather than mapping them using LoadLibrary when core clr is enabled. 2) Modify the verifier or other code that assumes on-disk layout to be able to work with mapped sections as well. I would prefer to do what Silverlight does. Kornél Lucas Meijer wrote: Hey, In order to figure out how to properly use the new coreclr functionality, verifiers etc, I've taken the test-metadata.c sample that shows how to simply embed mono, and I'm adding some coreclr stuff to it. The sample works and runs fine with core clr disabled. If I add: mono_security_enable_core_clr (); before mono_jit_init(), the mscorlib fails to load. When stepping trough the program with a debugger, the point where these two (with coreclr and without) diverge, is that line 465 of coree.c: ModuleHandle = LoadLibrary(FileName); returns a valid handle when coreclr is turned off, and it returns 0 when coreclr is turned on. This is on windows, with r135921 runtime+corlib, using msvc2008 built mono using the stock msvc projectfile. I'm a bit surprised by this actually, as I wouldn't expect a call into the win32 api to behave differently based on the coreclr settings. (the FileName variable is identical in both cases). Am I doing something wrong? A verifier related question: in do_mono_image_load(), there are these calls: mono_verifier_verify_pe_data(). this one requires image-raw_data_len to be set. (in verify_msdos_header) mono_verifier_load_pe_data(). this one actually sets image-raw_data_len. (in do_load_header) they're executed in the order above, which causes the first one to always fail for me. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NET_4_0 Configure Flags
--enable-net-4-0 --disable-net-4-0 --enable-net-1-1 --disable-net-1-1 etc. would make more sense I think because most likely there will be more versions and there is no use to call any specific version preview or legacy. Jonathan Pobst wrote: Recently we added the .Net 4.0 profile to the Mono build. Unfortunately, at this point, there isn't much there for the majority of users, and it nearly doubles the build time. Do we have a make guru who can resurrect our --with-preview=no configure flag and change it so it turns off the 4.0 profile instead of the 2.0 profile? (Or a new, similar flag if we want to still be able to turn off the 2.0 profile.) I would suggest that until we are doing sizable development on 4.0, this should default to no. For bonus points, it would be nice to have a --with-legacy flag that turns off building the 1.1 profile (except what is needed for bootstrap of course). ;) Jonathan ___ 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-list] Agreement Novell - Microsoft
Hi, The only thing you can fear are software patents. Microsoft can't do anything else to Mono. Also note that existing Mono source code will reamain available under the current open source licenses even if licensing policy changes for future releases. See http://www.mono-project.com/Licensing#Patents Kornél 666lawyer írta: Richard Stallman: Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#. So I think it's dangerous to use C#, and it may be dangerous to use Mono. There's nothing wrong with Mono. Mono is a free implementation of a language that users use. It's good to provide free implementations. We should have free implementations of every language. But, depending on it is dangerous, and we better not do that. Alan McGovern-2 wrote: Nope, they don't own or directly fund the mono project. Alan. On Thu, Jun 4, 2009 at 1:33 PM, 666lawyer 666law...@gmail.com wrote: Is true that Microsoft is reserved the right to abort the mono project at any moment? -- View this message in context: http://www.nabble.com/Agreement-Novell---Microsoft-tp23868979p23868979.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Hi,
These two internal types are present in all .NET Framework versions.
HttpNotFoundHandler is exposed by default Web.config in .NET Framework 2.0.
HttpNotImplementedHandler is documented in book Professional ASP.NET 2.0
Security, Membership, and Role Management, page 66:
http://books.google.com/books?id=Qt3TeJJkG5oC
Kornél
Index: mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
===
--- mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
(revision 0)
+++ mcs/class/System.Web/System.Web/HttpNotImplementedHandler.cs
(revision 0)
@@ -0,0 +1,46 @@
+//
+// System.Web.HttpNotImplementedHandler.cs
+//
+// Author:
+// Kornél Pál http://www.kornelpal.com/
+//
+// Copyright (C) 2009 Kornél Pál
+//
+
+//
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// Software), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+//
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+namespace System.Web
+{
+ internal class HttpNotImplementedHandler : IHttpHandler
+ {
+ public void ProcessRequest (HttpContext context)
+ {
+ HttpRequest request = context.Request;
+
+ throw new HttpException (501, request.HttpMethod +
+ request.Path + is not implemented.);
+ }
+
+ public bool IsReusable {
+ get { return true; }
+ }
+ }
+}
Property changes on:
mcs\class\System.Web\System.Web\HttpNotImplementedHandler.cs
___
Name: svn:eol-style
+ native
Index: mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs
===
--- mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
+++ mcs/class/System.Web/System.Web/HttpNotFoundHandler.cs (revision 0)
@@ -0,0 +1,46 @@
+//
+// System.Web.HttpNotFoundHandler.cs
+//
+// Author:
+// Kornél Pál http://www.kornelpal.com/
+//
+// Copyright (C) 2009 Kornél Pál
+//
+
+//
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// Software), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+//
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+namespace System.Web
+{
+ internal class HttpNotFoundHandler : IHttpHandler
+ {
+ public void ProcessRequest (HttpContext context)
+ {
+ string path = context.Request.Path;
+
+ throw new HttpException (404, Path ' + path + ' was
not found., path);
+ }
+
+ public bool IsReusable {
+ get { return true; }
+ }
+ }
+}
Property changes on: mcs\class\System.Web\System.Web\HttpNotFoundHandler.cs
___
Name: svn:eol-style
+ native
Index: mcs/class/System.Web/System.Web20.csproj
===
--- mcs/class/System.Web/System.Web20.csproj(revision 135657)
+++ mcs/class
Re: [Mono-dev] [PATCH] Improved ParseParameterData for fastcgi-mono-server [2]
Attached a fixed version.
Kornél Pál wrote:
Hi,
This patch properly implements PATH_INFO conversion to file path and
path info. This behavior is consistent with the behavior of Apache and PHP.
Another goal is to make it faster.
Please review the patch.
Kornél
Index: src/Mono.WebServer.FastCgi/Request.cs
===
--- src/Mono.WebServer.FastCgi/Request.cs (revision 135508)
+++ src/Mono.WebServer.FastCgi/Request.cs (working copy)
@@ -35,6 +35,7 @@
#endif
using System.IO;
using System.Text;
+using IOPath = System.IO.Path;
namespace Mono.FastCgi {
public class Request
@@ -424,14 +425,17 @@
/// /summary
void ParseParameterData ()
{
- string scriptName = GetParameter (SCRIPT_NAME);
- if (scriptName == null || scriptName.Length == 0)
+ string redirectUrl = GetParameter (REDIRECT_URL);
+ if (redirectUrl == null || redirectUrl.Length == 0)
return;
string pathInfo = GetParameter (PATH_INFO);
if (pathInfo == null || pathInfo.Length == 0)
return;
+ if (pathInfo [0] != '/' || pathInfo != redirectUrl)
+ return;
+
string pathTranslated = GetParameter
(PATH_TRANSLATED);
if (pathTranslated == null || pathTranslated.Length ==
0)
return;
@@ -440,53 +444,98 @@
if (documentRoot == null || documentRoot.Length == 0)
return;
- string redirectUrl = GetParameter (REDIRECT_URL);
- if (redirectUrl == null || redirectUrl.Length == 0)
- return;
-
- if (pathInfo != redirectUrl ||
!pathInfo.StartsWith(/))
- return;
-
- string[] parts = pathInfo.Split ('/');
-
- // at this point we have:
+ // At this point we have:
//
// REDIRECT_URL=/dir/test.aspx/foo
// PATH_INFO=/dir/test.aspx/foo
- // PATH_TRANSLATED=/srv/www/htdoc/dir/test.aspx/foo
+ // PATH_TRANSLATED=/srv/www/htdocs/dir/test.aspx/foo
// SCRIPT_NAME=/cgi-bin/fastcgi-mono-server
// SCRIPT_FILENAME=/srv/www/cgi-bin/fastcgi-mono-server
- // DOCUMENT_ROOT=/srv/www/htdoc
+ // DOCUMENT_ROOT=/srv/www/htdocs
- for (int i = parts.Length - 1; i = 0; i--) {
- string vpath = Combine (parts, 1, i);
- string ppath = System.IO.Path.GetFullPath
(documentRoot + vpath);
+ bool trailingSlash = pathTranslated
[pathTranslated.Length - 1] == '/' ||
+ (IOPath.DirectorySeparatorChar != '/'
pathTranslated [pathTranslated.Length - 1] == IOPath.DirectorySeparatorChar);
- if (!File.Exists (ppath))
- continue;
+ if ((!trailingSlash !File.Exists (pathTranslated))
|| (trailingSlash !Directory.Exists (pathTranslated))) {
+ char [] separators;
+ string physPath = pathTranslated;
+ string filePath = null;
- // now we set:
- //
- // PATH_INFO=/foo
- // PATH_TRANSLATED=/srv/www/htdoc/dir/foo
- // SCRIPT_NAME=/dir/test.aspx
- // SCRIPT_FILENAME=/srv/www/htdocs/dir/test.aspx
-
- SetParameter (SCRIPT_NAME, vpath);
- SetParameter (SCRIPT_FILENAME, ppath);
-
- if (i == parts.Length - 1) {
- SetParameter (PATH_INFO, null);
- SetParameter (PATH_TRANSLATED, null);
- } else {
- string pt = Combine (parts, i + 1,
parts.Length - 1);
- SetParameter (PATH_INFO, pt);
- SetParameter (PATH_TRANSLATED,
-
System.IO.Path.GetFullPath (documentRoot + pt));
+ if (IOPath.DirectorySeparatorChar == '/')
+ separators = null
[Mono-dev] [PATCH] Improved ParseParameterData for fastcgi-mono-server
Hi,
This patch properly implements PATH_INFO conversion to file path and
path info. This behavior is consistent with the behavior of Apache and PHP.
Another goal is to make it faster.
Please review the patch.
Kornél
Index: src/Mono.WebServer.FastCgi/Request.cs
===
--- src/Mono.WebServer.FastCgi/Request.cs (revision 135508)
+++ src/Mono.WebServer.FastCgi/Request.cs (working copy)
@@ -35,6 +35,7 @@
#endif
using System.IO;
using System.Text;
+using IOPath = System.IO.Path;
namespace Mono.FastCgi {
public class Request
@@ -424,14 +425,17 @@
/// /summary
void ParseParameterData ()
{
- string scriptName = GetParameter (SCRIPT_NAME);
- if (scriptName == null || scriptName.Length == 0)
+ string redirectUrl = GetParameter (REDIRECT_URL);
+ if (redirectUrl == null || redirectUrl.Length == 0)
return;
string pathInfo = GetParameter (PATH_INFO);
if (pathInfo == null || pathInfo.Length == 0)
return;
+ if (pathInfo [0] != '/' || pathInfo != redirectUrl)
+ return;
+
string pathTranslated = GetParameter
(PATH_TRANSLATED);
if (pathTranslated == null || pathTranslated.Length ==
0)
return;
@@ -440,16 +444,7 @@
if (documentRoot == null || documentRoot.Length == 0)
return;
- string redirectUrl = GetParameter (REDIRECT_URL);
- if (redirectUrl == null || redirectUrl.Length == 0)
- return;
-
- if (pathInfo != redirectUrl ||
!pathInfo.StartsWith(/))
- return;
-
- string[] parts = pathInfo.Split ('/');
-
- // at this point we have:
+ // At this point we have:
//
// REDIRECT_URL=/dir/test.aspx/foo
// PATH_INFO=/dir/test.aspx/foo
@@ -458,33 +453,86 @@
// SCRIPT_FILENAME=/srv/www/cgi-bin/fastcgi-mono-server
// DOCUMENT_ROOT=/srv/www/htdoc
- for (int i = parts.Length - 1; i = 0; i--) {
- string vpath = Combine (parts, 1, i);
- string ppath = System.IO.Path.GetFullPath
(documentRoot + vpath);
+ bool trailingSlash = pathTranslated
[pathTranslated.Length - 1] == '/' ||
+ (IOPath.DirectorySeparatorChar != '/'
pathTranslated [pathTranslated.Length - 1] == IOPath.DirectorySeparatorChar);
- if (!File.Exists (ppath))
- continue;
+ if ((trailingSlash !Directory.Exists
(pathTranslated)) || (!trailingSlash !File.Exists (pathTranslated))) {
+ char [] separators;
+ string physPath = pathTranslated;
+ string filePath = null;
- // now we set:
- //
- // PATH_INFO=/foo
- // PATH_TRANSLATED=/srv/www/htdoc/dir/foo
- // SCRIPT_NAME=/dir/test.aspx
- // SCRIPT_FILENAME=/srv/www/htdocs/dir/test.aspx
-
- SetParameter (SCRIPT_NAME, vpath);
- SetParameter (SCRIPT_FILENAME, ppath);
-
- if (i == parts.Length - 1) {
- SetParameter (PATH_INFO, null);
- SetParameter (PATH_TRANSLATED, null);
- } else {
- string pt = Combine (parts, i + 1,
parts.Length - 1);
- SetParameter (PATH_INFO, pt);
- SetParameter (PATH_TRANSLATED,
-
System.IO.Path.GetFullPath (documentRoot + pt));
+ if (IOPath.DirectorySeparatorChar == '/')
+ separators = null;
+ else
+ separators = new char [] { '/',
IOPath.DirectorySeparatorChar };
+
+ // Reverse scan until the first existing file
because access to parent
+ // directories may be denied.
+
Re: [Mono-dev] [PATCH] Adding to the PInvoke search path.
Hi, What about searching prefix/lib as well automatically that would eliminate the need for LD_LIBRARY_PATH when using prefix not searched by ld? Kornél 2009/6/1 Bill Holmes billholme...@gmail.com: Hi, The attached patch was discussed on IRC last week. We found that MS.Net uses the directory of the declaring assembly when searching for shared libraries to invoke unmanaged code. The outcome of the conversation was that we did not want the behavior by default in Mono. However an environment variable could control this behavior. Whit this patch setting MONO_PINVOKE_SEARCH to USE_ASSEMBLY_PATH will enable this. -bill 2009-06-01 Bill Holmes billholme...@gmail.com * loader.c (mono_loader_init): Check for and process the MONO_PINVOKE_SEARCH environment variable. * loader.c (mono_lookup_pinvoke_call): If MONO_PINVOKE_SEARCH is set to USE_ASSEMBLY_PATH, add the declaring assembly directory to resolve shared libraries. Code is contributed under 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] [PATCH] FastCGI patch
Hi, Cygwin can be configured but bash will accept only one of them once configured. This means that we either have to use CR/LF or LF everywhere. When no EOL style is set then the original line break style is preserved and native means CR/LF even for cygwin's SVN on Windows (according to my experience). If I set CR/LF on cygwin I wouldn't be able to compile Mono so I prefer to use LF for shell scripts. Tools other than bash have no problem with either line break styles. Kornél Robert Jordan wrote: Andreas Färber wrote: Am 02.06.2009 um 02:14 schrieb Kornél Pál: autogen.sh, configure.in: Set eol style to Unix to fix cygwin build. Can Cygwin no longer be configured to use either eol style? Although Cygwin's SVN defaults to LF, other SVN tools for Windows do not. When the working copy was created by another tool cygwin's bash is failing with incomprehensible error messages. The issue is not prevalent (except for xsp) because other *.in and *.sh in mono's trees do not have svn:eol-style set. 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-dev] ASP.NET is supported using CGI
Hi, I was very happy when I realized that Mono has support for FastCGI because that means that CGI can easily be supported as well. I actually managed to use ASP.NET pages using a shared hosting plan. I've created a new article in the hope that others find it useful and that Mono will be available to a larger audience. See http://www.mono-project.com/CGI Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] FastCGI patch
Hi,
ChangeLog:
autogen.sh, configure.in: Set eol style to Unix to fix cygwin build.
Responder.cs (Process): Properly set status code when no application is
found.
Request.cs (ParseParameterData): Use a simple reverse scan of path
components until the first existing file and allow non-existent files.
Please review the patch.
Kornél
Property changes on: configure.in
___
Name: svn:eol-style
- native
+ LF
Index: src/Mono.WebServer.FastCgi/Request.cs
===
--- src/Mono.WebServer.FastCgi/Request.cs (revision 135169)
+++ src/Mono.WebServer.FastCgi/Request.cs (working copy)
@@ -444,13 +444,10 @@
if (redirectUrl == null || redirectUrl == String.Empty)
return;
- if (pathInfo != redirectUrl)
+ if (pathInfo != redirectUrl ||
!pathInfo.StartsWith(/))
return;
string[] parts = pathInfo.Split ('/');
- // we expect at least / + path-component.
- if (parts.Length 2)
- return;
// at this point we have:
//
@@ -459,39 +456,42 @@
// PATH_TRANSLATED=/srv/www/htdoc/dir/test.aspx/foo
// SCRIPT_NAME=/cgi-bin/fastcgi-mono-server
// SCRIPT_FILENAME=/srv/www/cgi-bin/fastcgi-mono-server
-
- for (int i = 1; i parts.Length; i++) {
+ // DOCUMENT_ROOT=/srv/www/htdoc
+
+ for (int i = parts.Length - 1; i = 0; i--)
+ {
string vpath = Combine (parts, 1, i);
string ppath = System.IO.Path.GetFullPath
(documentRoot + vpath);
- bool isFile = File.Exists (ppath);
- bool isDir = Directory.Exists (ppath);
- if (!(isFile || isDir))
- break;
+ if (!File.Exists (ppath))
+ continue;
- if (isFile || i == parts.Length - 1) {
- // now we set:
- //
- // PATH_INFO=/foo
- //
PATH_TRANSLATED=/srv/www/htdoc/dir/foo
- // SCRIPT_NAME=/dir/test.aspx
- //
SCRIPT_FILENAME=/srv/www/htdocs/dir/test.aspx
-
- SetParameter (SCRIPT_NAME, vpath);
- SetParameter (SCRIPT_FILENAME, ppath);
-
- if (i == parts.Length - 1) {
- SetParameter (PATH_INFO,
null);
- SetParameter
(PATH_TRANSLATED, null);
- } else {
- string pt = Combine (parts, i +
1, parts.Length - 1);
- SetParameter (PATH_INFO, pt);
- SetParameter (PATH_TRANSLATED,
-
System.IO.Path.GetFullPath (documentRoot + pt));
- }
- break;
+ // now we set:
+ //
+ // PATH_INFO=/foo
+ // PATH_TRANSLATED=/srv/www/htdoc/dir/foo
+ // SCRIPT_NAME=/dir/test.aspx
+ // SCRIPT_FILENAME=/srv/www/htdocs/dir/test.aspx
+
+ SetParameter (SCRIPT_NAME, vpath);
+ SetParameter (SCRIPT_FILENAME, ppath);
+
+ if (i == parts.Length - 1) {
+ SetParameter (PATH_INFO, null);
+ SetParameter (PATH_TRANSLATED, null);
+ } else {
+ string pt = Combine (parts, i + 1,
parts.Length - 1);
+ SetParameter (PATH_INFO, pt);
+ SetParameter (PATH_TRANSLATED,
+
System.IO.Path.GetFullPath (documentRoot + pt));
}
+
[Mono-list] ASP.NET is supported using CGI
Hi, I was very happy when I realized that Mono has support for FastCGI because that means that CGI can easily be supported as well. I actually managed to use ASP.NET pages using a shared hosting plan. I've created a new article in the hope that others find it useful and that Mono will be available to a larger audience. See http://www.mono-project.com/CGI Kornél ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] DLL Created in Visual Basic 6.0 can run on cross platform
Hi, I belive that the problem with VB6 is that it massively depends on third party closed source ActiveX DLLs and OCXes written in C that are very unlikely to be available on Linux without Wine. I think that there are two reasonable solutions: 1) Use genuine VB6 on Wine. 2) Convert the project to VB.NET, remove ActiveX dependencies and use Mono. In my opinion other conversions are not worth. Kornél Pedro Alves wrote: An alternative would be using Jabaco (www.jabaco.org http://www.jabaco.org). You write sourcecode similar to VB6 and with Jabaco you can compile it to bytecode which is similar to the output of the Java programing language. If the Jabaco generate code for the Mono would be great! But... :/ []s Pedro Alves www.pedrojr.net http://www.pedrojr.net 2009/5/22 Rolf Bjarne Kvinge rolfli...@ya.com mailto:rolfli...@ya.com Hi, i have a .dll created in visual basic 6.0. now i want to run that .dll in linux platform, so how can i do this?. Use wine (http://www.winehq.org/) is it possible with mono framework? if so then can you guide me how to start?, how to compile?, how to execute? If you absolutely do not want to use wine, you need to convert your VB6 dll/project/application to VB7+ using Visual Studio first, when you got it working in Windows, you just copy your application to a linux machine where you have mono installed and execute 'mono myapp.exe'. Rolf can you tell me what are the steps to use mono framework? i will be thankfull to all of you... -- View this message in context: http://www.nabble.com/DLL-Created-in- Visual-Basic-6.0-can-run-on-cross-platform-tp23611949p23611949.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] DLL Created in Visual Basic 6.0 can run on cross platform
Hi, I'm aware of this. I just mean that if you convert VB6 source code to VB.NET, or that other language variant that targets the JVM, your code most likely still will not be platform independent because VB6 source code usually is heavily dependent on ActiveX DLLs. Kornél Chris Howie wrote: 2009/5/22 Kornél Pál kornel...@gmail.com: I belive that the problem with VB6 is that it massively depends on third party closed source ActiveX DLLs and OCXes written in C that are very unlikely to be available on Linux without Wine. No, the problem is that VB6 does not compile things to CIL, it compiles them to either native x86 or P-Code. The MS.NET and Mono runtimes don't know how to run anything but CIL (or AOT'd CIL). In other words, you can't run VB6 on Mono for the same reasons you can't run an x86 app on a PPC machine. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] Implement mono_thread_get_stack_bounds on windows
Hi, Nice patch. You should use DWORD_PTR instad of DWORD and DWORD64 that would unifiy 32-bit and 64-bit parts. I also believe that you mean widely known instead of wildly know in the ChangeLog. Kornél Rodrigo Kumpera wrote: And, of course, I forgot to attach the patch. On Wed, May 20, 2009 at 7:31 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Forgot to mention that there is another well know hack to discover stack bounds and why I rather like this one. The hack is to use VirtualQuery on %esp and expand the range to upward regions. I think the VirtualQuery hack is worse as it works by using a somewhat ok heuristics and OTOH the NtCurrentTe one provides precise information and I doubt it will disapear overnight. On Wed, May 20, 2009 at 7:25 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Hey, Attached is a patch that implements this function on windows. Tested only on XP/win32. Cheers, 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
[Mono-dev] [PATCH] Use trampolines for vtable fixups
Hi,
The attached patch implements using trampolines for vtable fixups that
delay assembly loading. I believe that this is the correct solution.
This patch also modifies:
1) EXE image is only fixed up when using driver.c; embedded mono.dll
will not improperly tamper the image used for version initialization.
2) Use SEH with MS VC++ for reading mapped image. (GCC has no support
for that:( )
3) Disallow unloading mono.dll after mscoree.dll was fixed up to prevent
calling unmapped functions.
4) Remove WaitForSingleObjectEx in mono_gc_init () by modifying
mono_thread_create_internal to return the thread object.
This latter also affects other platform. I would like to ask you to test
it. I wasn't able to reproduce any deadlock related to this. (I only
found a deadlock with socket accept on Windows that was discussed
earlier on the list.) If you can reproduce a deadlock related to
finalizer thread I am willing to help solving that but I need the exact
locaions of deadlocked thread stack traces.
Kornél
Index: mono/mono/metadata/domain.c
===
--- mono/mono/metadata/domain.c (revision 133502)
+++ mono/mono/metadata/domain.c (working copy)
@@ -1256,7 +1256,7 @@
/* Avoid system error message boxes. */
SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX);
- mono_load_coree (exe_filename);
+ mono_load_coree ();
#endif
mono_perfcounters_init ();
@@ -1294,14 +1294,6 @@
* exe_image, and close it during shutdown.
*/
get_runtimes_from_exe (exe_filename, exe_image, runtimes);
-#ifdef PLATFORM_WIN32
- if (!exe_image) {
- exe_image = mono_assembly_open_from_bundle (exe_filename, NULL, FALSE);
- if (!exe_image)
-exe_image = mono_image_open (exe_filename, NULL);
- }
- mono_fixup_exe_image (exe_image);
-#endif
} else if (runtime_version != NULL) {
runtimes [0] = get_runtime_by_version (runtime_version);
runtimes [1] = NULL;
Index: mono/mono/metadata/assembly.c
===
--- mono/mono/metadata/assembly.c (revision 133502)
+++ mono/mono/metadata/assembly.c (working copy)
@@ -1520,11 +1520,6 @@
loaded_assemblies = g_list_prepend (loaded_assemblies, ass);
mono_assemblies_unlock ();
-#ifdef PLATFORM_WIN32
- if (image-is_module_handle)
- mono_image_fixup_vtable (image);
-#endif
-
mono_assembly_invoke_load_hook (ass);
mono_profiler_assembly_loaded (ass, MONO_PROFILE_OK);
Index: mono/mono/metadata/coree.c
===
--- mono/mono/metadata/coree.c (revision 133502)
+++ mono/mono/metadata/coree.c (working copy)
@@ -35,13 +35,10 @@
HMODULE coree_module_handle = NULL;
-static gboolean init_from_coree = FALSE;
-
-gchar*
-mono_get_module_file_name (HMODULE module_handle)
+static gunichar2*
+mono_get_module_file_name_utf16 (HMODULE module_handle)
{
gunichar2* file_name;
- gchar* file_name_utf8;
DWORD buffer_size;
DWORD size;
@@ -63,9 +60,19 @@
file_name = g_realloc (file_name, buffer_size * sizeof (gunichar2));
}
- file_name_utf8 = g_utf16_to_utf8 (file_name, size, NULL, NULL, NULL);
- g_free (file_name);
+ return file_name;
+}
+gchar*
+mono_get_module_file_name (HMODULE module_handle)
+{
+ gunichar2* file_name_utf16;
+ gchar* file_name_utf8;
+
+ file_name_utf16 = mono_get_module_file_name_utf16 (module_handle);
+ file_name_utf8 = g_utf16_to_utf8 (file_name_utf16, -1, NULL, NULL, NULL);
+ g_free (file_name_utf16);
+
return file_name_utf8;
}
@@ -87,7 +94,6 @@
if (mono_get_root_domain ()) {
image = mono_image_open_from_module_handle (hInst, mono_path_resolve_symlinks (file_name), TRUE, NULL);
} else {
- init_from_coree = TRUE;
mono_runtime_load (file_name, NULL);
error = (gchar*) mono_check_corlib_version ();
if (error) {
@@ -106,20 +112,12 @@
}
}
- if (!image) {
- g_free (file_name);
+ g_free (file_name);
+
+ if (!image)
return FALSE;
- }
- /*
- * FIXME: Find a better way to call mono_image_fixup_vtable. Only
- * loader trampolines should be used and assembly loading should
- * probably be delayed until the first call to an exported function.
- */
- if (image-tables [MONO_TABLE_ASSEMBLY].rows ((MonoCLIImageInfo*) image-image_info)-cli_cli_header.ch_vtable_fixups.rva)
- assembly = mono_assembly_open (file_name, NULL);
-
- g_free (file_name);
+ mono_image_fixup_vtable (image);
break;
case DLL_PROCESS_DETACH:
if (lpReserved != NULL)
@@ -153,7 +151,6 @@
int i;
file_name = mono_get_module_file_name (NULL);
- init_from_coree = TRUE;
domain = mono_runtime_load (file_name, NULL);
error = (gchar*) mono_check_corlib_version ();
@@ -198,6 +195,7 @@
argv [i] = g_utf16_to_utf8 (argvw [i], -1, NULL, NULL, NULL);
LocalFree (argvw);
+ mono_image_fixup_vtable (image);
mono_runtime_run_main (method, argc, argv, NULL);
mono_thread_manage ();
@@ -429,34 +427,41 @@
if (DosHeader ==
Re: [Mono-dev] [PATCH] Use trampolines for vtable fixups
The ChangeLog is in the e-mail. Final changelog will be a bit more detailed but I believe this is not the final patch yet. Most of the code is not in PLATFORM_WIN32 so I would like to ask people to test this patch on other platforms as well. The SEH stuff can't break gcc because it's in _MSC_VER. Kornél Rodrigo Kumpera wrote: Hi Kornel, Your patch have a few issues. First, it does a lot of different stuff in the same patch, second no Changelog entries are provided. My suggestion is that yo split it in the following pieces and add Changelog entries so they can properly reviewed: -The change to mono_gc_init (). This affects all platforms and require more reviewer effort that the rest. -SEH for reading mapped images. Can this change break cygwin/mingw builds? -coree/vtable fixups stuff. This one requires less reviewing as your're the author of it and it doesn't affect other targets. Thanks, Rodrigo 2009/5/5 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com Hi, The attached patch implements using trampolines for vtable fixups that delay assembly loading. I believe that this is the correct solution. This patch also modifies: 1) EXE image is only fixed up when using driver.c; embedded mono.dll will not improperly tamper the image used for version initialization. 2) Use SEH with MS VC++ for reading mapped image. (GCC has no support for that:( ) 3) Disallow unloading mono.dll after mscoree.dll was fixed up to prevent calling unmapped functions. 4) Remove WaitForSingleObjectEx in mono_gc_init () by modifying mono_thread_create_internal to return the thread object. This latter also affects other platform. I would like to ask you to test it. I wasn't able to reproduce any deadlock related to this. (I only found a deadlock with socket accept on Windows that was discussed earlier on the list.) If you can reproduce a deadlock related to finalizer thread I am willing to help solving that but I need the exact locaions of deadlocked thread stack traces. Kornél ___ 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-list] mscoree.dll crash
Hi, MSVCRT is calling CorExitProcess on exit if mscoree.dll is loaded. mono.dll is hooking some mscoree.dll exports (including CorExitProcess) to itself but is not removing these hooks on unload. I suggest you to keep an extra reference to mono.dll so that it will not be unloaded until process termination. This is a bug that should definitely be fixed but I will need some time to come up with an optimal solution. Kornél fozzie wrote: The problem occurs when a separate DLL is pulled into the central executable via LoadLibrary(). On shutdown of the executable the DLL is freed via FreeLibrary() and this results in unload of mono.dll, which changes the mscoree.dll address space. The debug work directory should be set to $(OutDir) or mscorlib.dll will not be found. There is a breakpoint immediately after mono_jit_init_version() to allow examination of the address of CorExitProcess. The lib and etc directories from the Mono 2.4 install should be copied below bin\mono\. The following are copied from the install directories to the bin\debug directory. They aren't big so i kept them in the zip: libglib-2.0-0.dll libgmodule-2.0-0.dll libgthread-2.0-0.dll I tried uploading the file in both Chrome and IE 8, but it doesn't seem to work so i've stuck it at http://rapidshare.com/files/226924363/mscoree_crash.zip.html. Hopefully it helps to track this down. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] mscorlib.dll is an invalid CIL image
mscorlib.dll is tightly integrated with the runtime so mixing the runtime and mscorlib.dll is guaranteed not to work. Verify the same mscorlib.dll that you want to use using peverify.exe from MS.NET for example or on another box with Mono. Also ensure that the file isn't corrupted by non-binary trasfer. Verify its md5sum for example. If mscorlib.dll is OK the your runtime is corrupt of compliled incorrectly. Kornél Chris Plasun wrote: Thanks for your reply Rodrigo. I copied mcorlib.dll both from the Microsoft .NET distribution and from the Mono distribution so it should be valid. I tried various versions. The Mono version is 2.2 and it is cross compiled for powerpc-e300c3 Is there a standard powerpc-e300c3 version of Mono that I can use? Can I use ANY version of Mono for the PowerPC? How would I trace into the error I'm receiving? Thanks again. Chris Plasun From: Rodrigo Kumpera kump...@gmail.com To: Chris Plasun chrisp...@yahoo.com Cc: mono-devel-list@lists.ximian.com Sent: Tuesday, April 28, 2009 12:23:53 PM Subject: Re: [Mono-dev] mscorlib.dll is an invalid CIL image This might be a bug in your mscorlib.dll or the mono runtime decoding functions. What version of mono are you using? Did you cross compile or built on the host? Is your mscorlib really valid? On Tue, Apr 28, 2009 at 3:56 PM, Chris Plasun chrisp...@yahoo.com wrote: Hi, I'm trying to get Mono working on a Freescale MPC8313 PowerPC embedded Linux board. When I try to run a 'hello world' application I get the following error: mscorlib.dll is an invalid CIL image I've looked around on Google and I have **nothing** that gets me a step further. I'm out of options as far as I know. Does anyone know how I can fix this issue? Thank you for any help. Chris Plasun ___ 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-list] mscoree.dll crash
Could you please provide a test project (source and executable) that causes this crash? Thanks. Kornél fozzie wrote: On application shutdown, FreeLibrary() is called to unload the DLL which calls mono_jit_init_version(). The debugger shows that the final NtUnmapViewOfSection() during the FreeLibrary() processing causes unload of mono.dll and trashing of the mscoree.dll memory area holding the executable instructions for CorExitProcess(). But mscoree.dll is not unloaded for some reason so a crash occurs later when the CRT shuts down. Still digging.. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mscoree.dll crash
Hi, I've written the things in coree.c and it is hooking exported functions in mscoree.dll to functions in mono.dll. This may cause the crash you have described but I need a test case to fix that. Kornél fozzie wrote: Unfortunately the source in question is proprietary, but i'll try to create a smaller sample to reproduce the crash. For some reason, the sample teste project does not. It looks like coree.c is doing a fair bit of lifetime management :). I'm using source checked out via svn co svn://anonsvn.mono-project.com/source/branches/mono-2-4/mono with the standard Mono 2.4 install on Windows Vista 32-bit. Perhaps i'm missing some patches? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi, I don't really use profile 1.0. On MS.NET you can expect not to have 2.0 installed but since Mono has support for 1.0 and 2.0 at once there is no need to stick to 1.0. Over the time resisting generics is more and more difficult.:) The only reason I've implemented that piece of code was that I've read in the commnet that not having DynamicMethods is a problem and I wanted to prove that the same is possible using MethodBuilders without modifying a single line of the code generator. And telling the truth it was very easy to implement. The difficult part was to eliminate the chain of methods and the unused DynamicMethod arguments because it took time to reallize that none of them is used just are left over from some early implementation. I believe however that having a stripped down runtime and (partial) class library without generics support could be useful in embedded scenarios. For example there are routers running Linux with 8 MB RAM and 2 MB flash. (I'm not suggesting that Mono should target them just noticing the fact that even in the age of gigabytes there are devices with just a few megabytes of RAM and storage.) Kornél Miguel de Icaza wrote: Hello, I've implement support for compiled regular expressions in profile 1.x using dynamic assemblies. I am curious: how important is 1.0 for you, and why are you using 1.0 instead of 2.0? We are having a discussion about dropping support for 1.0 from Mono to make our lives easier and I am trying to understand if there are any important cases that we have overlooked. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi,
The runtime has support for generic types in profile 1.0 as well,
OnDeserializedAttribute could also be used, just like new case
insensitive and culture invariant string operations/comparison, static
classes could be supported by profile 1.0 C# compiler because no runtime
support is needed, and this is just some examples of possible 2.0 suff
for internal use in 1.0 class library.
As far as I know none of them or any other 2.0 features are used outside
of mscorlib.dll.
Also note that this is a complete patch including replacing the generic
Dictionaries with non-generic Hashtables.
Attached a more recent version of the patch with some minor updates.
Kornél
Rodrigo Kumpera wrote:
I think a better approach instead of using dynamic assemblies is to use
dynamic methods on 1.0 as well.
They can be exposed as internal stuff from mscorlib to System and most
of the work will replacing the generic
stuff.
2009/4/2 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com
Hi,
Because of the restrictions of 1.x I modified visibility so I also would
like to set skipVisibility = false in DynamicMethod constructor (not
included in the patch) to avoid 1.x only bugs because of this.
Kornél
Kornél Pál wrote:
Hi,
I've implement support for compiled regular expressions in
profile 1.x
using dynamic assemblies.
I also have cleaned up the code by removing GetEvalMethod and
CreateEvalMethod methods and moving their functionality to
GetMachineFactory.
I also modified the signature of EmitEvalMethodBody and replaced
generic
dictionaries with hashtables in profile 1.x that results in a larger
patch but I haven't modify the actual code generator.
I also had to modify some visibility levels to pass runtime type
checks.
Please review the attached patch.
Kornél
___
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
Index: RxCompiler.cs
===
--- RxCompiler.cs (revision 130801)
+++ RxCompiler.cs (working copy)
@@ -727,15 +727,33 @@
}
class RxInterpreterFactory : IMachineFactory {
+#if NET_2_0
+ private EvalDelegate eval_del;
+
public RxInterpreterFactory (byte[] program, EvalDelegate
eval_del) {
this.program = program;
this.eval_del = eval_del;
}
-
+
public IMachine NewInstance () {
return new RxInterpreter (program, eval_del);
}
+#else
+ private Type type;
+ public RxInterpreterFactory (byte[] program, Type type) {
+ this.program = program;
+ this.type = type;
+ }
+
+ public IMachine NewInstance () {
+ if (type == null)
+ return new RxInterpreter (program);
+
+ return (RxInterpreter) Activator.CreateInstance (type,
BindingFlags.CreateInstance | BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Instance, null, new object[] { program }, null, null);
+ }
+#endif
+
public int GroupCount {
get {
return (int)program [1] | ((int)program [2]
8);
@@ -754,7 +772,6 @@
private IDictionary mapping;
private byte[] program;
- private EvalDelegate eval_del;
private string[] namesMapping;
}
Index: RxInterpreter.cs
===
--- RxInterpreter.cs(revision 130801)
+++ RxInterpreter.cs(working copy)
@@ -8,26 +8,30 @@
namespace System.Text.RegularExpressions {
+#if NET_2_0
internal delegate bool EvalDelegate (RxInterpreter interp, int strpos,
ref int strpos_result);
+#endif
- sealed class RxInterpreter: BaseMachine {
- byte[] program;
- string str;
- int string_start;
- int string_end;
+ class RxInterpreter: BaseMachine {
+ public byte[] program;
+ public string str;
+ public int string_start;
+ public int string_end;
int group_count;
// int match_start;
- int[] groups;
+ public int[] groups;
+#if NET_2_0
EvalDelegate eval_del; // optimized EvalByteCode method created
by the CILCompiler
+#endif
- Mark[] marks = null; // mark stack
+ public Mark[] marks = null; // mark stack
int mark_start
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
I think that using public fields instead of private ones costs no work. Parts of this patch related to dynamic assemblies are just a few lines that is complete and needs no maintenace. I didn't have to change a single character in the code generator so the part that really needs maintenance is not affected by this solution. On the other hand maintaining implementations using generic and non-generic hashtables needs maintenance. Most of the things is about introducing non-generic Hashtables and getting rid of GetEvalMethod and CreateEvalMethod methods and making EmitEvalMethodBody return boolean instead of the single DynamicMethod instance ever created in the flow or null. These latter things help maintaining code but most likely won't be accepted either because are not required if we don't want support without DynamicMethods. Anyway I'm not going to push this patch, I just implemented this because this was very straightforward to implement and this solution (at least to me) seems to be very straightforward. Kornél Rodrigo Kumpera wrote: Kornél, Using dynamic assemblies will increase the maintenance burden for no good advantage. It should be done with dynamic methods, if at all. 2009/4/3 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com Hi, The runtime has support for generic types in profile 1.0 as well, OnDeserializedAttribute could also be used, just like new case insensitive and culture invariant string operations/comparison, static classes could be supported by profile 1.0 C# compiler because no runtime support is needed, and this is just some examples of possible 2.0 suff for internal use in 1.0 class library. As far as I know none of them or any other 2.0 features are used outside of mscorlib.dll. Also note that this is a complete patch including replacing the generic Dictionaries with non-generic Hashtables. Attached a more recent version of the patch with some minor updates. Kornél Rodrigo Kumpera wrote: I think a better approach instead of using dynamic assemblies is to use dynamic methods on 1.0 as well. They can be exposed as internal stuff from mscorlib to System and most of the work will replacing the generic stuff. 2009/4/2 Kornél Pál kornel...@gmail.com mailto:kornel...@gmail.com mailto:kornel...@gmail.com mailto:kornel...@gmail.com Hi, Because of the restrictions of 1.x I modified visibility so I also would like to set skipVisibility = false in DynamicMethod constructor (not included in the patch) to avoid 1.x only bugs because of this. Kornél Kornél Pál wrote: Hi, I've implement support for compiled regular expressions in profile 1.x using dynamic assemblies. I also have cleaned up the code by removing GetEvalMethod and CreateEvalMethod methods and moving their functionality to GetMachineFactory. I also modified the signature of EmitEvalMethodBody and replaced generic dictionaries with hashtables in profile 1.x that results in a larger patch but I haven't modify the actual code generator. I also had to modify some visibility levels to pass runtime type checks. Please review the attached patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi, Because of the restrictions of 1.x I modified visibility so I also would like to set skipVisibility = false in DynamicMethod constructor (not included in the patch) to avoid 1.x only bugs because of this. Kornél Kornél Pál wrote: Hi, I've implement support for compiled regular expressions in profile 1.x using dynamic assemblies. I also have cleaned up the code by removing GetEvalMethod and CreateEvalMethod methods and moving their functionality to GetMachineFactory. I also modified the signature of EmitEvalMethodBody and replaced generic dictionaries with hashtables in profile 1.x that results in a larger patch but I haven't modify the actual code generator. I also had to modify some visibility levels to pass runtime type checks. Please review the attached patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi,
I've implement support for compiled regular expressions in profile 1.x
using dynamic assemblies.
I also have cleaned up the code by removing GetEvalMethod and
CreateEvalMethod methods and moving their functionality to
GetMachineFactory.
I also modified the signature of EmitEvalMethodBody and replaced generic
dictionaries with hashtables in profile 1.x that results in a larger
patch but I haven't modify the actual code generator.
I also had to modify some visibility levels to pass runtime type checks.
Please review the attached patch.
Kornél
Index: RxCompiler.cs
===
--- RxCompiler.cs (revision 130801)
+++ RxCompiler.cs (working copy)
@@ -727,15 +727,33 @@
}
class RxInterpreterFactory : IMachineFactory {
+#if NET_2_0
+ private EvalDelegate eval_del;
+
public RxInterpreterFactory (byte[] program, EvalDelegate
eval_del) {
this.program = program;
this.eval_del = eval_del;
}
-
+
public IMachine NewInstance () {
return new RxInterpreter (program, eval_del);
}
+#else
+ private Type type;
+ public RxInterpreterFactory (byte[] program, Type type) {
+ this.program = program;
+ this.type = type;
+ }
+
+ public IMachine NewInstance () {
+ if (type == null)
+ return new RxInterpreter (program);
+
+ return (IMachine) Activator.CreateInstance (type,
BindingFlags.CreateInstance | BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Instance, null, new object[] { program }, null, null);
+ }
+#endif
+
public int GroupCount {
get {
return (int)program [1] | ((int)program [2]
8);
@@ -754,7 +772,6 @@
private IDictionary mapping;
private byte[] program;
- private EvalDelegate eval_del;
private string[] namesMapping;
}
Index: RxInterpreter.cs
===
--- RxInterpreter.cs(revision 130801)
+++ RxInterpreter.cs(working copy)
@@ -8,26 +8,30 @@
namespace System.Text.RegularExpressions {
+#if NET_2_0
internal delegate bool EvalDelegate (RxInterpreter interp, int strpos,
ref int strpos_result);
+#endif
- sealed class RxInterpreter: BaseMachine {
- byte[] program;
- string str;
- int string_start;
- int string_end;
+ class RxInterpreter: BaseMachine {
+ public byte[] program;
+ public string str;
+ public int string_start;
+ public int string_end;
int group_count;
// int match_start;
- int[] groups;
+ public int[] groups;
+#if NET_2_0
EvalDelegate eval_del; // optimized EvalByteCode method created
by the CILCompiler
+#endif
- Mark[] marks = null; // mark stack
+ public Mark[] marks = null; // mark stack
int mark_start; // start of current checkpoint
int mark_end; // end of checkpoint/next free mark
- IntStack stack; // utility stack
+ public IntStack stack; // utility stack
RepeatContext repeat; // current repeat context
- RepeatContext deep; // points to the most-nested
repeat context
+ public RepeatContext deep; // points to the most-nested
repeat context
/* The readonly ensures the JIT can optimize out if (trace_rx)
statements */
public static readonly bool trace_rx =
@@ -73,7 +77,7 @@
}
}
- private class RepeatContext {
+ internal class RepeatContext {
public RepeatContext (RepeatContext previous, int min,
int max, bool lazy, int expr_pc) {
this.previous = previous;
this.min = min;
@@ -133,11 +137,17 @@
return val;
}
+#if NET_2_0
public RxInterpreter (byte[] program, EvalDelegate eval_del)
+#else
+ public RxInterpreter (byte[] program)
+#endif
{
this.program = program;
+#if NET_2_0
this.eval_del = eval_del;
- group_count = 1 + (program [1] | ((int)program [2]
8));
+#endif
+ group_count = 1 + (program [1] | ((int) program [2]
8));
groups = new int [group_count];
stack
Re: [Mono-dev] [PATCH] Changes for CreateThread calls.
Wouldn't just this be enough? in mono_thread_create_internal: #ifdef PLATFORM_WIN32 DWORD tid; #else gsize tid; #endif Kornél Bill Holmes wrote: Hi, The attached patch fixes some problems I was seeing with thread IDs on Winx64. What I found was that the thread ID argument of CreateThread is a ulong which is not 64 bits on Winx64. So when called with the address of a size variable the top 32 bits are garbage. This patch simply initializes all thread ID variables to zero before calling CreateThread. Is there a better way to fix this? -bill 2009-03-25 Bill Holmes billholme...@gmail.com * appdomain.c (mono_domain_unload), * attach.c (transport_start_receive), * threads.c (mono_thread_create_internal), * threads.c (ves_icall_System_Threading_Thread_Thread_internal): Initialize the tid variable to 0 before calls to CreateThread. This is needed for Winx64 because that argument is only 32 bits. Code is contributed under 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] Mono on Windows Native NT API
Hi, You will get a very limited functionality because ntdll isn't the only user mode module enabling you to access kernel mode services. Also note that large parts of CreateProcess are implemented outside of ntdll. Anyway I would suggest you to port the io-layer to native NT API. You may need modifications in other parts as well but this is the best solution I can think of if you really don't want to use kernel32.dll and advapi32.dll. Kornél Peacebreaker wrote: Hi folks, since a couple of weeks I am playing with the very core of Windows (Server 2003) and managed to trim down the OS to about 8MB (6.5MB with ntfs compression) on disk running only the NT kernel with a number of drivers (bus, fs, net...). I wrote a very very basic console in c that starts in user mode after kernel initialization is done (replacing the session manager subsystem). As I am not that pleased with having to code c I wondered if one could get .Net applications to run at this level. That's where mono comes into play. So my question is: Is it possible (with moderate effort) to port Mono to native NT API? There is no Win32 API at all (user32.dll, advapi.dll...). The only thing that's left of Windows is just the plain native NT API (ntdll.dll). It is possible? Where do I have to start? What are the functions to look at? Where can I find the related parts in the mono source code? Of course there is no need for GUI support or other high level stuff. Thanks in advance, Peace ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] More .NET and mono floating point inconsistencies
Hi, At least on x86 changing the FPU's control flags is expensive so it usually runs with 64-bit precision. (Both Mono and MS.NET use it as double is 64-bit sized.) There may be architectures that support different size floating point operations simultaneously but on x86 you have to use one size and convert the results to lower precision when needed. As a result float (float32) and double (float64) work either at the same speed, or float32 is slower when you do a lot of float64 to float32 conversions on the FP stack without storing it to a variable. The only thing you save is storage when you store float32 out of the FP stack. Kornél ddambro wrote: Kornél, Thank you for looking into this issue for me. After adding a few more explicit float conversions and removing some temporary variables, I was able to create a version of my program that runs the same on both mono (svn127604) and .NET. However, I am interested in what you said about doubles. If I'm understanding correctly, if I use doubles instead of floats I shouldn't have to worry about these rounding inconsistencies? I think we started with doubles, but moved to floats because they were supposedly faster, but if what you say is true, I might try and change everything over when I have time. Checking Google only reveals that there is some conflict as to if floats are faster than doubles in C#. Plus if I ever decide to use the SIMD instructions, I can only do half as much work at a time. But even if there is a performance loss it might be worth it to avoid constantly having to test new versions for .NET/mono compatibility. David Kornél Pál wrote: David, I've evaluated your test cases and found that the behavior exposed by your tests cases is not a bug. For the first sight this seems to be a bug is MS.NET, but it isn't a bug of MS.NET either. ECMA specs (part3, 1.1.1 Numeric data types) explicitly state the following: When a floating-point value ... is put in a storage location, it is automatically coerced to the type of the storage location. ... However, the value might be retained in the internal representation for future use, if it is reloaded from the storage location without having been modified. ... This freedom to carry extra precision is not permitted, however, following the execution of an explicit conversion (conv.r4 or conv.r8) ... This means that unlike integer variables, floating point store/load pairs are not (necessarily) cause conversion. On the other hand if you need deterministic behavior, you should issue an explicit conv.r4 (x = (float)y; in C#) because this is an implementation detail of the current MS JIT compiler that may change in the future even in that compiler. Although ECMA specs permit the native float type to have additional precision, you will most likely never notice the same behavior with double (float64), because both Mono and MS.NET configure the FPU to round each arithmetic operations to 64-bits. Also note that there is no performance gain from using float (float32), because the FPU still operates in 64-bit mode that has to be converted to 32-bits. As a result if you want performance you shouldn't use float32 at all. A simplified test case: float f1=200; float f2=162.980057f; float f3 = (1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Adding an extra conversion you will get the behavior of Mono on MS.NET as well: float f1=200; float f2=162.980057f; float f3 = (float)(1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Kornél Rodrigo Kumpera wrote: I have commited the fixed from Kornél for all bugs that have tests. On Fri, Feb 20, 2009 at 12:14 AM, ddambro ddam...@gmail.com mailto:ddam...@gmail.com wrote: Hi, Thanks for looking into my issues. I hope my post didn't come across as rude or anything, I was really just looking to ask if it was better to post issues here or directly to Bugzilla. I'm sure there are far more important issues than my weird floating point inconsistencies. For the curious, I am an AI researcher working on Evolutionary Computation. I tend to use Windows and .NET to run my code, but my research group has several large computing clusters that could massively speed up my experiments, but they only run Linux. Also academia tends to shy away from Windows Only software, so if I can say Runs in Linux when I release my code to the public, it's a pretty big boon for me as well as the people who want to run it. However, because of the floating point issues described, experiments run on mono are not compatible with experiments run on .NET, as over the course of a simulation, the small errors propagate over thousands of time steps into large differences in the final AI
Re: [Mono-list] More .NET and mono floating point inconsistencies
David, I've evaluated your test cases and found that the behavior exposed by your tests cases is not a bug. For the first sight this seems to be a bug is MS.NET, but it isn't a bug of MS.NET either. ECMA specs (part3, 1.1.1 Numeric data types) explicitly state the following: When a floating-point value ... is put in a storage location, it is automatically coerced to the type of the storage location. ... However, the value might be retained in the internal representation for future use, if it is reloaded from the storage location without having been modified. ... This freedom to carry extra precision is not permitted, however, following the execution of an explicit conversion (conv.r4 or conv.r8) ... This means that unlike integer variables, floating point store/load pairs are not (necessarily) cause conversion. On the other hand if you need deterministic behavior, you should issue an explicit conv.r4 (x = (float)y; in C#) because this is an implementation detail of the current MS JIT compiler that may change in the future even in that compiler. Although ECMA specs permit the native float type to have additional precision, you will most likely never notice the same behavior with double (float64), because both Mono and MS.NET configure the FPU to round each arithmetic operations to 64-bits. Also note that there is no performance gain from using float (float32), because the FPU still operates in 64-bit mode that has to be converted to 32-bits. As a result if you want performance you shouldn't use float32 at all. A simplified test case: float f1=200; float f2=162.980057f; float f3 = (1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Adding an extra conversion you will get the behavior of Mono on MS.NET as well: float f1=200; float f2=162.980057f; float f3 = (float)(1 - (f2 / f1)); float f4 = f3*f3; Console.WriteLine(f4.ToString(R, CultureInfo.InvariantCulture)); Kornél Rodrigo Kumpera wrote: I have commited the fixed from Kornél for all bugs that have tests. On Fri, Feb 20, 2009 at 12:14 AM, ddambro ddam...@gmail.com mailto:ddam...@gmail.com wrote: Hi, Thanks for looking into my issues. I hope my post didn't come across as rude or anything, I was really just looking to ask if it was better to post issues here or directly to Bugzilla. I'm sure there are far more important issues than my weird floating point inconsistencies. For the curious, I am an AI researcher working on Evolutionary Computation. I tend to use Windows and .NET to run my code, but my research group has several large computing clusters that could massively speed up my experiments, but they only run Linux. Also academia tends to shy away from Windows Only software, so if I can say Runs in Linux when I release my code to the public, it's a pretty big boon for me as well as the people who want to run it. However, because of the floating point issues described, experiments run on mono are not compatible with experiments run on .NET, as over the course of a simulation, the small errors propagate over thousands of time steps into large differences in the final AI behavior. Thus, if I used both mono and .NET, not only would I have to be mindful of which experiment was run on which platform when I do analysis and demonstrations, but when I release my results to the public I would also have to mark arbitrary sets of experiments as mono only or .NET only. Kornél Pál wrote: Hi, Thanks for the test cases, I'll invetigate these as well and try to fix them. The best way to get bugs fixed is to produce test cases and report them in buzilla. You can help more if you are able to provide a patch to fix the bugs. Note that for some reasons Novell guys seem to ignore this bug mostly because they have other things to do and their approval is required for these changes. Could you please describe your scenario (application name, purpose, etc. if they are public) where you need these floating point roundings and describe why these bugs are critical for you. Providing some description may raise component owners' attention. Kornél ddambro wrote: I previously posted about some differences I noticed between the floating point math in .NET and mono http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-to21428695ef1367.html here . The bug report can be found https://bugzilla.novell.com/show_bug.cgi?id=467201 here . The patch provided (Thank you!) fixes several issues I was encountering, but unfortunately it led me to discover a couple more. The following two
Re: [Mono-list] Why is mono so slow at math compared to .Net?
As I see Mono is using a lot of more advanced and faster technologies/techniques than .NET in core features. The code generator of the JIT however lacks low level optimizations that could eliminate and/or combine native instruction sequences. Kornél Jon Harrop wrote: On Wednesday 18 February 2009 20:30:39 Robert Weiss wrote: No *more* than 50% slower??? I really hope you are kidding me. Why? .NET is one of the world's most advanced VM implementations and Microsoft have put tremendous resources into building it. Competing with it is *extremely* difficult and will require not only a lot of cash but also a lot of talent. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] Cannot compile Mono on Windows
Hi, When compiling profile 2.0 assemblies using trunk most mcs mono processes either remain alive after finishing executing that prevents make from proceeding - or - return to make prior to exiting and printig some messages after that while make cannot stat the resulting .dll file that causes error in make. This prevents compilation on Windows that is a very serious problem. Any help is appreciated. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] More .NET and mono floating point inconsistencies
Hi,
Thanks for the test cases, I'll invetigate these as well and try to fix
them.
The best way to get bugs fixed is to produce test cases and report them
in buzilla.
You can help more if you are able to provide a patch to fix the bugs.
Note that for some reasons Novell guys seem to ignore this bug mostly
because they have other things to do and their approval is required for
these changes.
Could you please describe your scenario (application name, purpose, etc.
if they are public) where you need these floating point roundings and
describe why these bugs are critical for you.
Providing some description may raise component owners' attention.
Kornél
ddambro wrote:
I previously posted about some differences I noticed between the floating
point math in .NET and mono
http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-to21428695ef1367.html
here . The bug report can be found
https://bugzilla.novell.com/show_bug.cgi?id=467201 here . The patch
provided (Thank you!) fixes several issues I was encountering, but
unfortunately it led me to discover a couple more. The following two code
samples were tested x86 machines using Linux mono 2.2 with the patch found
in the bug report, a clean Windows mono 2.0.1, and the latest version of
.NET targeting 3.0 framework and x86.
---
1.
using System;
using System.Runtime.CompilerServices;
class Testing
{
[MethodImpl(MethodImplOptions.NoInlining)]
public static void Main()
{
float f1=200;
float distance=Distance(300, 500, 387.5f, 362.5f);
float dist = 1 - (distance / f1);
float distSqud = dist * dist;
Console.WriteLine(distSqud.ToString(R));
foreach (byte b in BitConverter.GetBytes(distSqud))
Console.WriteLine(b);
}
public static float Distance(float x1, float y1, float x2, float y2)
{
float xDist = x1 - x2;
float yDist = y1 - y2;
float dist = (float)Math.Sqrt(xDist * xDist + yDist * yDist);
return dist;
}
On .NET this code produces:
0.0342619047
54
86
12
61
and on mono it produces:
0.03426191
55
86
12
61
---
2.
using System;
using System.Runtime.CompilerServices;
class Testing
{
[MethodImpl(MethodImplOptions.NoInlining)]
public static void Main()
{
float distance = Distance(616.161255f, 391.2928f, 550.8382f,
131.006973f);
Console.WriteLine(distance.ToString(R));
foreach (byte b in BitConverter.GetBytes(distance))
Console.WriteLine(b);
}
public static float Distance(float x1, float y1, float x2, float y2)
{
float xDist = x1 - x2;
float yDist = y1 - y2;
float dist = (float)Math.Sqrt(xDist * xDist + yDist * yDist);
Console.WriteLine(dist.ToString(R));
foreach (byte b in BitConverter.GetBytes(dist))
Console.WriteLine(b);
return dist;
}
}
On .NET this code produces:
268.3576
198
45
134
67
268.3576
198
45
134
67
and on mono it produces:
268.357635
199
45
134
67
268.357635
199
45
134
67
---
These seem to be very similar to the issues I was encountering before, but
they are not fixed by the patch. What is the best way to resolve these
inconsistencies?
Thanks,
David
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 2...
Hi, Could you please track this as well: https://bugzilla.novell.com/show_bug.cgi?id=467201 Kornél ___ 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 IntPtr bug
Russell, The CLI has first class support for IntPtr but C# unfortunately needs to call IntPtr methods instead of using opcodes directly. But I believe that these methods should be inlined by the runtime. (If not this should be tracked in bugzilla.) And as Rodrigo said you should use unsafe code with pointer if you want maximal performance because C# has support for pointers and is using unsigned native int arythmetic for them. Also note that pointers are in fact unsigned so you should convert them to usingned integers to avoid sign related issues. And your patch Russell is incorrect because IntPtr is a signed integer that is 32-bit on 32-bit architectures this it cannot hold UInt32.MaxValue. If you want to hold UInt32.MaxValue you should use UIntPtr. Kornél Rodrigo Kumpera wrote: IntPtr code should optimize as well as int on 32bits machines and long on 64 bits machine. If it's not the case, report it. Working with ints using long will be a lot slower on 32bits machines for sure. Regarding doing pointer math, the usual way to do it with C# is to use a block of unsafe code and use proper pointer types. On Wed, Feb 11, 2009 at 3:12 PM, russell@realtimeworlds.com mailto:russell@realtimeworlds.com wrote: Rodrigo, IntPtr objects are very awkward to use and optimise badly, we unwrap an IntPtr to an internal type called Ptr, that is an enum based on a long, as this generates much better code within loops and generally inlines better (on both Mono and MS.Net) we also keep this as a long so that we have the same assembly on both x86 and x64 (which limits our testing). IntPtr is also fairly horrible to work with when you are doing any maths when working with memory operations (which we are doing a lot). Now this is not a problem and works very well on both Mono and MS.NET http://MS.NET , when this patch is applied. I do not see the objection to this patch as an IntPtr can safely hold values that are over 2Gb and they are valid addresses, also converting from a pointer to a long does not sign extend it, which is perfectly valid and at times you do want to convert back to an IntPtr. This is a perfectly safe and sensible patch. Russell *From:* Rodrigo Kumpera [mailto:kump...@gmail.com mailto:kump...@gmail.com] *Sent:* 11 February 2009 17:01 *To:* Russell Kay *Cc:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Patch for IntPtr bug Russel, I think the issue is that you're using long to represent pointers when you should be using IntPtr only. 2009/2/11 russell@realtimeworlds.com mailto:russell@realtimeworlds.com All, Not sure the best way to submit this, please correct me if there is a better way to do this (via bugzilla?) I encountered a problem when casting a long to an IntPtr, which is something we have ended up doing a lot (we want to keep binary assembly compatibility between x86 and x64, only changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com
Re: [Mono-dev] Fwd: Ideas for Mono on Windows
Eberhard Beilharz wrote: 3) the build process hang when building mono/docs, so I looked in the Makefile of that directory and did a touch on the files it tried to create (some *.tree and *.zip files). I figured since it's only documentation it doesn't matter if I have those files or not. That's a bug in Mono so you should neglect it unless you are willing to fix it. The other things all could be fixed by a proper build environment. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Use ECMA compliant floating point rounding (x86)
Hi,
This patch fixes the test cases in
https://bugzilla.novell.com/show_bug.cgi?id=467201
I've found the following bugs:
1. Return value of functions don't has to be rounded and is not rounded
by MS.NET either.
2. conv.r4 has to change precision (required by ECMA specs)
3. conv.r8 also has to change precision
I also reordered code in OP_LCONV_TO_R_UN_2 because there is no need to
allocate extra stack space and store and reload a 80-bit floating point
value. I just removed unnecessary code but please have a look at the
changes because I have little experience with the FPU.
Also note that the test in the bug report should be modified to be
platform independent and the above three bugs should be fixed on all
other platforms that has them.
Kornél
Index: mono/mono/mini/cpu-x86.md
===
--- mono/mono/mini/cpu-x86.md (revision 124272)
+++ mono/mono/mini/cpu-x86.md (working copy)
@@ -96,7 +96,7 @@
int_conv_to_i1: dest:i src1:y len:3
int_conv_to_i2: dest:i src1:i len:3
int_conv_to_i4: dest:i src1:i len:2
-int_conv_to_r4: dest:f src1:i len:7
+int_conv_to_r4: dest:f src1:i len:13
int_conv_to_r8: dest:f src1:i len:7
int_conv_to_u4: dest:i src1:i
int_conv_to_u2: dest:i src1:i len:3
@@ -128,9 +128,9 @@
voidcall: len:17 clob:c
voidcall_reg: src1:i len:11 clob:c
voidcall_membase: src1:b len:16 clob:c
-fcall: dest:f len:48 clob:c
-fcall_reg: dest:f src1:i len:48 clob:c
-fcall_membase: dest:f src1:b len:48 clob:c
+fcall: dest:f len:17 clob:c
+fcall_reg: dest:f src1:i len:11 clob:c
+fcall_membase: dest:f src1:b len:16 clob:c
lcall: dest:l len:17 clob:c
lcall_reg: dest:l src1:i len:11 clob:c
lcall_membase: dest:l src1:b len:16 clob:c
@@ -376,12 +376,12 @@
cmov_ilt_un: dest:i src1:i src2:i len:16 clob:1
long_conv_to_ovf_i4_2: dest:i src1:i src2:i len:30
-long_conv_to_r8_2: dest:f src1:i src2:i len:37
-long_conv_to_r4_2: dest:f src1:i src2:i len:64
-long_conv_to_r_un_2: dest:f src1:i src2:i len:37
+long_conv_to_r8_2: dest:f src1:i src2:i len:14
+long_conv_to_r4_2: dest:f src1:i src2:i len:14
+long_conv_to_r_un_2: dest:f src1:i src2:i len:20
fmove: dest:f src1:f
-float_conv_to_r4: dest:f src1:f
+float_conv_to_r4: dest:f src1:f len:12
load_mem: dest:i len:9
loadi4_mem: dest:i len:9
Index: mono/mono/mini/mini-x86.c
===
--- mono/mono/mini/mini-x86.c (revision 124272)
+++ mono/mono/mini/mini-x86.c (working copy)
@@ -1838,17 +1838,6 @@
}
}
break;
- case OP_FCALL: {
- MonoCallInst *call = (MonoCallInst*)ins;
- if (call-method !mono_method_signature
(call-method)-ret-byref mono_method_signature (call-method)-ret-type
== MONO_TYPE_R4) {
- /* Avoid some precision issues by saving/reloading the
return value */
- x86_alu_reg_imm (code, X86_SUB, X86_ESP, 8);
- x86_fst_membase (code, X86_ESP, 0, FALSE, TRUE);
- x86_fld_membase (code, X86_ESP, 0, FALSE);
- x86_alu_reg_imm (code, X86_ADD, X86_ESP, 8);
- }
- break;
- }
default:
break;
}
@@ -2956,7 +2945,14 @@
case OP_LOADR4_MEMBASE:
x86_fld_membase (code, ins-inst_basereg,
ins-inst_offset, FALSE);
break;
- case OP_ICONV_TO_R4: /* FIXME: change precision */
+ case OP_ICONV_TO_R4:
+ x86_push_reg (code, ins-sreg1);
+ x86_fild_membase (code, X86_ESP, 0, FALSE);
+ /* Change precision */
+ x86_fst_membase (code, X86_ESP, 0, FALSE, TRUE);
+ x86_fld_membase (code, X86_ESP, 0, FALSE);
+ x86_alu_reg_imm (code, X86_ADD, X86_ESP, 4);
+ break;
case OP_ICONV_TO_R8:
x86_push_reg (code, ins-sreg1);
x86_fild_membase (code, X86_ESP, 0, FALSE);
@@ -2975,7 +2971,11 @@
x86_fild_membase (code, ins-inst_basereg,
ins-inst_offset, FALSE);
break;
case OP_FCONV_TO_R4:
- /* FIXME: nothing to do ?? */
+ /* Change precision */
+ x86_alu_reg_imm (code, X86_SUB, X86_ESP, 4);
+ x86_fst_membase (code, X86_ESP, 0, FALSE, TRUE);
+ x86_fld_membase (code, X86_ESP, 0, FALSE);
+ x86_alu_reg_imm (code, X86_ADD, X86_ESP, 4);
break;
case OP_FCONV_TO_I1:
code = emit_float_to_int (cfg, code, ins-dreg, 1,
TRUE);
@@ -3011,6 +3011,9 @@
x86_push_reg (code, ins-sreg2);
x86_push_reg (code,
Re: [Mono-dev] Class status pages are empty
Hi, Microsoft .NET Framework 2.0 Service Pack 2 finally was released as a standalone update: http://www.microsoft.com/downloads/details.aspx?FamilyID=5B2C0358-915B-4EB5-9B1D-10E506DA9D0Fdisplaylang=en As a result the following version should be used for comparison: 1.1 SP1 2.0 SP2 3.5 SP1 Updating to 2.0 SP2 would also render the but not for detecting if there are extra APIs (we will have them, as we are now tracking 3.5) clause obsolete. Also note that the actual status pages at http://go-mono.com/status are empty for me using Internet Explorer but work with Firefox. Kornél Atsushi Eno wrote: They are now at http://go-mono.com/status Atsushi Eno Leszek Ciesielski wrote: On Sun, Sep 21, 2008 at 7:30 PM, Miguel de Icaza mig...@novell.com wrote: Hello, Perhaps some members of the Mono team use gui-compare, but I think end-users / third-party developers appreciate an easy way to consult the API compatibility level of certain types/members. The only painful part of the online class status pages (that I see) is that the masterinfo files are not automatically updated (after changes to mono-api-info). This could be scheduled as part of the win32 buildbot though. Well, the masterinfo files are really static. Every time there is a new release, someone goes scavenging for all the files, and runs mono-api-info on the given assemblies and then we version the result. The actual masterinfos that we have are all listed in mono-tools/gui-compare/InfoManager.cs. Just grep for Uri there. So its merely an issue of fixing the build, and running more mono-api-diffs and generate more web pages for each of the profiles we want to compare. I think those should be: 1.1 2.0 3.5 SP1 On a side note: the generation of the masterinfo files is less that stellar. We have used a mix of the Reflection-based tools, and the Cecil tools to extract the information, and they are *slightly* different. In the last batch (done for 3.5SP1) I used the Cecil tools for half the assemblies (those that lived under Windows/) and reflection ones for the ones that live under Reference Assemblies because the Cecil ones required an assembly resolver that did not work. So the result is mixed. Does gui-compare use the same masterinfo input files (for .NET) as corcompare? Yes. Gert -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Miguel de Icaza Sent: zondag 21 september 2008 19:32 To: Gert Driesen Cc: 'mono-devel-list' Subject: Re: [Mono-dev] Class status pages are empty Hello, What was the reason for discontinuing the (online) class status pages? We never really discontinued it, at least in my case, I stopped caring. They were just difficult to maintain, and doing quick changes were not reflected quickly (we had to wait a few hours for either the process to run, or setup a local system which was never well documented and was messy). Chris Toshok wrote gui-compare, which was very useful to quickly iterate over an API and have since then barely used the Web UI. I am not sure if others have done it, but I think some of us just stopped using it. I agree that a web version has a lot of value, and would love to keep it around, but in its current form its painful to deal with. The other bit that is important to point out is that it has not been upgraded to deal with the various new profiles, that is something that would have to be done as well. Sorry for resurrecting an old discussion, but a lot of pages contain links to the Mono Class Status page. Which - if if understood this discussion - is no longer maintained. Could someone put a warning there that the page no longer works, and what should be used instead? ___ 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-list] Moonlight 1.0 released!!!
Hi, Is there a reason that only Linux on x86 and x86_64 is supported? I know little about Moonlight but since it's based on Mono I belive that a lot broader range of platforms could possibly be supported with small efforts. Kornél 2009/1/20 Rusty Howell rhow...@novell.com: Hey folks, We're very pleased to announce the release of Moonlight 1.0! The Firefox plugin is available at http://go-mono.com/moonlight for Linux 32 and 64 bit platforms. A tarball of Moonlight is available at http://ftp.novell.com/pub/mono/sources/moon/moon-1.0.tar.bz2 As always, any bugs found can be submitted to us at http://mono-project.com/Bugs . We're now looking forward to Moonlight 2.0 and the managed Silverlight goodness. Thanks again. Rusty Howell Moonlight QA ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] conv.r4 not implemented on x86?
Hi, This bug https://bugzilla.novell.com/show_bug.cgi?id=467201 seems to be that conv.r4 not implemented on x86. Unfortunately I don't know using what instructions should conv.r4 be implemented on x86. Could someone please look at this? Thanks. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi,
This seems to me a float32 rounding problem because when using float64 I
get the same results.
Code:
using System;
class Testing
{
public static void Main()
{
float f1 = 0;
f1 += -0.7779751f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 += -1f * -1.42317927f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 += -1.30905056f * 0.241778925f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 = (2.0F / (1.0F + (float)Math.Exp(-4.9F * f1))) - 1.0F;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
}
}
The last value is different indeed (I only thested on Windows):
MS:
0xa9c02a3f
0,667002261
Mono:
0xa8c02a3f
0,6670022
Hex value is different for me as well.
Kornél
Robert Jordan wrote:
ddambro wrote:
Hi,
I was fairly sure the code had executed. As I mentioned, different flags in
the C code caused errors in the program. Just to be sure though, I threw in
some fprintf statements to stderr into setFloats() and they printed
properly, so the code was definitely executed.
Thankfully I have been able to come up with some code that shows at least
one example of the inconsistencies I've been talking about. Here it is:
It's just a string representation mismatch, as this code reveals the
same bits:
Console.WriteLine(f1.ToString(R));
foreach (byte b in BitConverter.GetBytes(f1))
Console.WriteLine (b);
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi,
I've filed a bug report for this:
https://bugzilla.novell.com/show_bug.cgi?id=467201
Kornél
2009/1/19 ddambro ddam...@gmail.com:
I get the same results using Kornél's code. Using Robert's code compiled as
x86, run on various machines, OSes, and runtimes, I get the byte values as:
.NET:
169
192
42
63
mono:
168
192
42
63
So if this is a rounding issue, is there any way to get the two to round the
same? I think I've pretty much eliminated John's FPU suggestion as I went
through all the rounding flags and none of them matched .NET, and this issue
occurs in both Windows and Linux.
Kornél Pál wrote:
Hi,
This seems to me a float32 rounding problem because when using float64 I
get the same results.
Code:
using System;
class Testing
{
public static void Main()
{
float f1 = 0;
f1 += -0.7779751f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 += -1f * -1.42317927f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 += -1.30905056f * 0.241778925f;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
f1 = (2.0F / (1.0F + (float)Math.Exp(-4.9F * f1))) - 1.0F;
Console.Write(0x);
foreach (byte b in BitConverter.GetBytes(f1))
Console.Write (b.ToString(x2));
Console.WriteLine();
Console.WriteLine(f1.ToString(R));
}
}
The last value is different indeed (I only thested on Windows):
MS:
0xa9c02a3f
0,667002261
Mono:
0xa8c02a3f
0,6670022
Hex value is different for me as well.
Kornél
Robert Jordan wrote:
ddambro wrote:
Hi,
I was fairly sure the code had executed. As I mentioned, different
flags in
the C code caused errors in the program. Just to be sure though, I
threw in
some fprintf statements to stderr into setFloats() and they printed
properly, so the code was definitely executed.
Thankfully I have been able to come up with some code that shows at
least
one example of the inconsistencies I've been talking about. Here it is:
It's just a string representation mismatch, as this code reveals the
same bits:
Console.WriteLine(f1.ToString(R));
foreach (byte b in BitConverter.GetBytes(f1))
Console.WriteLine (b);
Robert
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
View this message in context:
http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21537058.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi, Please try the FPU flags suggested John to see if that solves your problem, modifying the control flags could be added to x86 versions of Mono so you wouldn't have to modify them manually. Kornél ddambro wrote: The code is compiled for x86 in Windows, and the problems I describe persist even using mono for Windows. That is, on every computer I've tried so far regardless of OS and processor type, all of the mono runs produce the same results and all of the .NET runs produce the same results, but these results are different from each other. This includes a 64-bit Vista machine running the x86 code in .NET and mono (installed as x86). How would this affect your suggested fix? Also I noticed a fairly significant speed up when I converted all my doubles to floats in this code a few years ago, would your fix undo that? mono already runs the code MUCH slower than .NET so I'd hate to get another performance hit. Dallman, John-2 wrote: when I take the same binary and run it with the same inputs it produces different outputs if it is run on mono and .Net. This is with Mono on Linux, and .NET on Windows? The executable is 32-bit .NET code? I suspect that you've hit a misfeature that exists for most floating-point code on 32-bit x86 Linux. The code to be run in the C function is: #include fpu_control.h/* Mask the Denormal, Underflow and Inexact exceptions, leaving Invalid, Overflow and Zero-divide active. Set precision to standard doubles, and round-to-nearest. */ fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM | _FPU_DOUBLE | _FPU_RC_NEAREST ; _FPU_SETCW( desired); This needs to be a C function because everything in uppercase in that code is a macro, from fpu_control.h. You may want to leave out enabling floating point traps, in which case the code becomes: #include fpu_control.h/* Set precision to standard doubles, and round-to-nearest. */ fpu_control_t desired = _FPU_DOUBLE | _FPU_RC_NEAREST ; _FPU_SETCW( desired); It would be good, really, if Mono had a standard call for setting up consistent floating-point on all its platforms. -- John Dallman Parasolid Porting Engineer Siemens PLM Software 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 john.dall...@siemens.com www.siemens.com/plm ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi,
DLLs are Windows specific are you sure you actually executed setFloats()
on Linux?
If you are unable to solve this issue using control flags we can't
figure out what your problem is without providing us a test case that
exhibits this behavior.
Please create a source code (can be as small as your wish) that can be
compiled without modifications so that other people will be able to
reproduce the problem.
Kornél
ddambro wrote:
I tried the FPU flags as follows:
1.Compiled the following file to a dll using gcc on a test linux system:
#include fpu_control.h
void setFloats()
{
fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM
|_FPU_DOUBLE | _FPU_RC_NEAREST ;
_FPU_SETCW( desired);
}
2.Added the following code to my main class in the C# code:
[DllImport(./floatTest.dll)]
public static extern void setFloats();
3.Called setFloats() before any other code.
The end results were the exact same as all my other mono runs and thus
different than my .NET runs. The C code without the masks caused my program
to throw divided by zero exceptions from Console.Writeline() and
File.Exists(). Are there other flags I can try or does the fact that this
happens on Windows mono and Linux mono point to something other than the FPU
setup? I'll keep looking for the exact spot where inconsistencies start to
happen and just to try it, I'm compiling mono 2.2 on a test machine to see
if that changes anything (everything so far has been on 2.0.2).
David
Kornél Pál wrote:
Hi,
Please try the FPU flags suggested John to see if that solves your
problem, modifying the control flags could be added to x86 versions of
Mono so you wouldn't have to modify them manually.
Kornél
ddambro wrote:
The code is compiled for x86 in Windows, and the problems I describe
persist
even using mono for Windows. That is, on every computer I've tried so
far
regardless of OS and processor type, all of the mono runs produce the
same
results and all of the .NET runs produce the same results, but these
results
are different from each other. This includes a 64-bit Vista machine
running
the x86 code in .NET and mono (installed as x86). How would this affect
your suggested fix? Also I noticed a fairly significant speed up when I
converted all my doubles to floats in this code a few years ago, would
your
fix undo that? mono already runs the code MUCH slower than .NET so I'd
hate
to get another performance hit.
Dallman, John-2 wrote:
when I take the same binary and run it with the same inputs it
produces different outputs if it is run on mono and .Net.
This is with Mono on Linux, and .NET on Windows? The executable
is 32-bit .NET code?
I suspect that you've hit a misfeature that exists for most
floating-point code on 32-bit x86 Linux.
The code to be run in the C function is:
#include fpu_control.h/* Mask the Denormal, Underflow and Inexact
exceptions,
leaving Invalid, Overflow and
Zero-divide active.
Set precision to standard doubles,
and round-to-nearest. */
fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM |
_FPU_DOUBLE | _FPU_RC_NEAREST ;
_FPU_SETCW( desired);
This needs to be a C function because everything in uppercase in
that code is a macro, from fpu_control.h. You may want to leave out
enabling floating point traps, in which case the code becomes:
#include fpu_control.h/* Set precision to standard doubles, and
round-to-nearest. */
fpu_control_t desired =_FPU_DOUBLE | _FPU_RC_NEAREST ;
_FPU_SETCW( desired);
It would be good, really, if Mono had a standard call for setting
up consistent floating-point on all its platforms.
--
John Dallman
Parasolid Porting Engineer
Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: +44-1223-371554
john.dall...@siemens.com
www.siemens.com/plm
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi, If you are sure that this is the case you should file a bug report because this could easily be solved in the runtime. Kornél Dallman, John wrote: when I take the same binary and run it with the same inputs it produces different outputs if it is run on mono and .Net. This is with Mono on Linux, and .NET on Windows? The executable is 32-bit .NET code? I suspect that you've hit a misfeature that exists for most floating-point code on 32-bit x86 Linux. It goes like this. The 32-bit floating-point registers (the x87 registers) are quite large, 80 bits long. This allows more precision than conventional double variables, which are 64 bits. There's a control register for setting what precision the processor should evaluate to, which has options of 32 bits (float), 64 bits (double) or 80 bits (long double). The idea was that you set up the precision you wanted to use, and that lower precision was faster. The power-up default is 80 bits, and Linux doesn't change that. However, lower precision is not faster any more. With tens of millions of transistors available, rather than tens of thousands, chip designers can use different floating-point methods that are much faster. So using 80bit precision is obviously the right thing to do? Well, no. You see, doubles in memory are 64 bits. And if you use 80 bit precision in the floating point processor, that means that when intermediate values get saved out to memory, they get rounded off to 64 bits, and then extended back to 80 bits when they're re- loaded. And those extension bits won't be the same as the ones that were discarded. Sadly, this is the way that floating point behaves by default on 32-bit x86 Linux. It introduces some noise into the results; one can't so much say that they are wrong, as that they aren't quite consistent with other platforms that use 64 bits consistently throughout the calculation process. Sparcs, PowerPCs, ARMs, and 64-bit x86 use 64-bit floating-point consistently. 32-bit Windows used to do floating-point the same way as 32-bit Linux does, but they changed it, so that when a Windows program starts up, the floating point has been set up to do 64 bits throughout. That's much more consistent with other platforms, and is an interesting instance of MS doing something arguably right even though awkward instead of consistent with past errors. But why not change it to whatever you need? Well, changing the floating point precision is Very Slow on modern processors. You have to completely flush the pipeline at minimum. It's much easier for it to be set at program start-up, and used consistently after that. To get this to work right in Mono, you need to write a small C function, and call it with P/Invoke on Linux. That means your program won't be pure .NET code anymore; how to best cope with that depends on your program. The code to be run in the C function is: #include fpu_control.h/* Mask the Denormal, Underflow and Inexact exceptions, leaving Invalid, Overflow and Zero-divide active. Set precision to standard doubles, and round-to-nearest. */ fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM | _FPU_DOUBLE | _FPU_RC_NEAREST ; _FPU_SETCW( desired); This needs to be a C function because everything in uppercase in that code is a macro, from fpu_control.h. You may want to leave out enabling floating point traps, in which case the code becomes: #include fpu_control.h/* Set precision to standard doubles, and round-to-nearest. */ fpu_control_t desired = _FPU_DOUBLE | _FPU_RC_NEAREST ; _FPU_SETCW( desired); It would be good, really, if Mono had a standard call for setting up consistent floating-point on all its platforms. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Announcing Mono 2.2 RC1...
Hi, Thomas Wiest wrote: Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs This is a very annoying bug and I would be happy if this could be fixed in Mono 2.2: https://bugzilla.novell.com/show_bug.cgi?id=458742 Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono version for Windows - why is there one?
Hi, .NET Framework is just a part of Windows so it makes sense to have a Windows port of Mono. This also helps making Mono more platform independent. You may also find useful to test your applications on Windows with Mono even if you target Linux because it is very similar to the Linux port. On the other hand you even can embed Mono to your application and take advantage of being able to strip unneeded parts to shrink the deployment size. Kornél niknil wrote: I've just started looking at Mono, and wonder why there is a Windows version available for download? Since Mono is a .NET port for Linux etc, it seems to me that it wouldn't be useful on Windows since .NET is already there. Sounds a bit like a Wine version for Windows. Obviously, I must be missing something, but what? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] RVA Irregularities
Hi,
I don't know how ProcessModule.BaseAddress is implemented on Linux but
you shouldn't use this.
If you want to look at the IL code open the file using FileStream or use
Cecil.
Note that even if you modify IL code that would not affect code that is
already compiled to native code.
Also note that RVA's are not required to be preserved when the image is
loaded to memory.
Mono on Windows is using LoadLibrary in most cases that will map the
image according to the RVAs but Linux has no support for PE files so
images are just loaded without mapping PE sections to their designated
virtual addresses.
Kornél
Nathan McCauley wrote:
The following code excerpt from the attached C# program behaves
differently on Mono 2.0.1runtime for Windows and Mono 2.0.1 runtime on
the OpenSUSE VMWare image. It contains a lookup of the base address
(contained in getBaseAddress()). The loop should print the program's
Main() function IL code at runtime. This RVA was found by looking it up
in ILDASM.
The program was compiled the MS compiler.
IntPtr baseAddr = getBaseAddress();
for (int offset = 0x211c; offset 0x2169; offset++)
{
Console.WriteLine(Addr = {0:X}\tByte = {1:X},
baseAddr.ToInt32() + offset,
Marshal.ReadByte(new IntPtr(baseAddr.ToInt32() + offset)));
}
It seems like the loader is behaving differently on each platform. Is
there something I should be doing to mitigate this behavior?
Windows Mono Runtime output:
Addr = 40211C Byte = 13
Addr = 40211D Byte = 30
Addr = 40211E Byte = 4
Addr = 40211F Byte = 0
Addr = 402120 Byte = 4B
Addr = 402121 Byte = 0
Addr = 402122 Byte = 0
Addr = 402123 Byte = 0
Addr = 402124 Byte = 2
Addr = 402125 Byte = 0
Addr = 402126 Byte = 0
Addr = 402127 Byte = 11
Addr = 402128 Byte = 28
Addr = 402129 Byte = 1
Addr = 40212A Byte = 0
Addr = 40212B Byte = 0
Addr = 40212C Byte = 6
Addr = 40212D Byte = A
Addr = 40212E Byte = 20
Addr = 40212F Byte = 1C
Addr = 402130 Byte = 21
Addr = 402131 Byte = 0
Addr = 402132 Byte = 0
Addr = 402133 Byte = B
Addr = 402134 Byte = 2B
Addr = 402135 Byte = 34
Addr = 402136 Byte = 72
Addr = 402137 Byte = 69
Addr = 402138 Byte = 0
Addr = 402139 Byte = 0
Linux Mono Runtime output:
Addr = B7DDB11C Byte = C
Addr = B7DDB11D Byte = 2
Addr = B7DDB11E Byte = 0
Addr = B7DDB11F Byte = 0
Addr = B7DDB120 Byte = 1
Addr = B7DDB121 Byte = 0
Addr = B7DDB122 Byte = 30
Addr = B7DDB123 Byte = 0
Addr = B7DDB124 Byte = 30
Addr = B7DDB125 Byte = 0
Addr = B7DDB126 Byte = 30
Addr = B7DDB127 Byte = 0
Addr = B7DDB128 Byte = 30
Addr = B7DDB129 Byte = 0
Addr = B7DDB12A Byte = 30
Addr = B7DDB12B Byte = 0
Addr = B7DDB12C Byte = 34
Addr = B7DDB12D Byte = 0
Addr = B7DDB12E Byte = 62
Addr = B7DDB12F Byte = 0
Addr = B7DDB130 Byte = 30
Addr = B7DDB131 Byte = 0
Addr = B7DDB132 Byte = 0
Addr = B7DDB133 Byte = 0
Addr = B7DDB134 Byte = 44
Addr = B7DDB135 Byte = 0
Addr = B7DDB136 Byte = E
Addr = B7DDB137 Byte = 0
Addr = B7DDB138 Byte = 1
Addr = B7DDB139 Byte = 0
___
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] patches that allow calling mono_init_com_types from native using ICall's.
Hi, Please implement initialization in unmanaged native code for GetIUnknownForObject and QueryInterface rather than exposing a private method that has to be called. COM interop should be compatible with MS.NET and this is a bug that should be fixed rather than worked around by exposing and externally calling an internal initialization function. Thanks. Kornél Tom Hindle wrote: Hi, Attached are two patches that allow calling mono_init_com_types using ICALL. the function mono_init_com_types() is usually called automatically when needed by the following internal functions in marshal.c emit_ptr_to_object_conv, emit_object_to_ptr_conv, emit_struct_conv, emit_marshal_com_interface, emit_marshal_variant, cominterop_get_native_wrapper, However in none of these functions have run it not possible to call functions like GetIUnknownForObjectInternal and QueryInterfaceInternal via ICALL. If this approach isn't acceptable would it be possible to add explicit calls to mono_init_com_types info methods like GetIUnknownForObjectInternal and QueryInterfaceInternal? Thanks Tom Hindle ___ 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] TcpChannel hang on Windows.
Hi,
I've modified the test case to call QueueUserAPC.
And both MS.NET and Mono (without your patch) seems to process the APC.
This still makes me think that the difference is in killing threads
rather than in Socket implementation.
When I uncommented thread.Abort(), both runtimes terminated the thread,
but MS.NET prints New thread state: Stopped while Mono prints New
thread state: Stopped, AbortRequested that may be the source of bugs.
Kornél
Bill Holmes wrote:
Kornél,
I tested your case and it appears to work fine with my changes. I
believe that this is because I check for the ThreadState_StopRequested
state. I do not check for ThreadState_AbortRequested. That is
intentional because that is the behavior I observed with MS .net.
Also if I understand it correctly mono_thread_manage wait on all non
background threads to complete before it sets the
ThreadState_StopRequested on the background threads only and waits for
those.
I also toggled the background flag in you example to ensure the two
runtimes behave the same.
Thanks so much for your review!
-bill
For those interested this is the case I am attempting to fix...
static void Main (string[] args)
{
TcpChannel tc = new TcpChannel (0);
}
using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using System.Runtime.InteropServices;
namespace BlockingAccept
{
class BlockingAccept
{
static Socket socket;
static IntPtr threadHandle;
delegate void APCProc(IntPtr dwParam);
[DllImport(kernel32.dll)]
static extern uint QueueUserAPC(APCProc pfnAPC, IntPtr hThread, IntPtr
dwData);
[DllImport(kernel32.dll)]
static extern IntPtr GetCurrentThread();
[DllImport(kernel32.dll)]
extern static IntPtr GetCurrentProcess();
[DllImport(kernel32.dll)]
extern static bool DuplicateHandle(IntPtr sourceProcessHandle, IntPtr
sourceHandle, IntPtr targetProcessHandle, out IntPtr targetHandle, uint
desiredAccess, bool inheritHandle, uint dwOptions);
[DllImport(kernel32.dll)]
extern static bool CloseHandle(IntPtr handle);
static void Main(string[] args)
{
Thread.BeginThreadAffinity();
Console.WriteLine(Main thread: + AppDomain.GetCurrentThreadId());
socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
socket.Blocking = true;
socket.Bind(new IPEndPoint(IPAddress.Loopback, 12345));
socket.Listen(1);
Thread thread = new Thread(AcceptSocket);
//thread.IsBackground = true;
thread.Start();
Thread.Sleep(1000);
//Console.WriteLine(before Abort);
//thread.Abort();
//Console.WriteLine(after Abort);
//Thread.Sleep(1000);
Console.WriteLine(New thread state: +
thread.ThreadState.ToString());
QueueUserAPC(APCCallback, threadHandle, IntPtr.Zero);
CloseHandle(threadHandle);
Thread.Sleep(1000);
Console.WriteLine(New thread state: +
thread.ThreadState.ToString());
Thread.EndThreadAffinity();
}
static void APCCallback(IntPtr dwParam)
{
Console.WriteLine(APCCallback thread: +
AppDomain.GetCurrentThreadId());
}
static void AcceptSocket()
{
Thread.BeginThreadAffinity();
Console.WriteLine(New thread: + AppDomain.GetCurrentThreadId());
DuplicateHandle(GetCurrentProcess(), GetCurrentThread(),
GetCurrentProcess(), out threadHandle, 0, false, 2);
Console.WriteLine(before Accept);
Socket conn = socket.Accept();
Console.WriteLine(after Accept);
conn.Close();
Thread.EndThreadAffinity();
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TcpChannel hang on Windows.
Hi, If you need a quick fix you patch will do it. But it is just a workaround. What I suggested is that the bug is general, not related to Socket.Accept. You wrote in your original message: The problem is that the APC call does not cause the accept call to break. My test case shows that the APC is executed even if accept is not leaved. I don't know the exact solution because I don't know what the real bug is. I just wanted to show you that Mono behaves the same as MS.NET except that the thread is not terminated at exit so I believe this is the difference rather than any hack in Socket.Accept. The difference in thread state is a bug I believe that may cause other bugs if code checks for exact state value but I don't know if this is the case. The fact that I used a managed APC is not required I just have written the test case in C#. I believe that in this case the thread is aborted because the wrapper checks for abortion. Kornél Bill Holmes wrote: Kornél, After reading your mail a bunch more times and messing with the sample I think I finally get what you were saying. What I discovered was that the APC callback being a managed method gives mono a chance to check the thread state when crossing to and from the managed thread boundary. It is not the fact that you called an APC that was important. What is important is that the APC was a managed call. This does in fact give me some ideas on new things to try. I will let you know what I find. I suspect that my new conclusion will be a risky change that will require much testing. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
