Re: [Mono-dev] WAPI Handle Leaks
Le vendredi 06 octobre 2006 10:08 +0200, Hubert FONGARNAND a crit: Le jeudi 05 octobre 2006 16:25 -0600, Patrick Earl a crit: I'm curious, is anyone out there doing much work in tracking down the wapi handle leak problems? Our XSP server dies on a daily basis because it's always running out of thread handles. Using 1.1.17.1 or the latest SVN version (r66235), the problem is there. I suspect there are problems with threads created internally (for example, as part of the thread pool) that aren't cleaned up by the garbage collector. I would be happy to help test, but solving the problem seems that it would require fairly in depth knowledge of the io layer, garbage collection, wapi handle usage, and such. Patrick Earl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list I experienced the same problem as you... I run mod-mono-server on my productions server, with very big applications (more than 100 aspx pages). I see that threads handles are always growing... (even when there's no request to the server!!!) I've sent graphs to Gonzalo to show my problem but i've no answer... Here's a 1 day graph showing the problem http://hfongarnand.free.fr/chart/wapi1.png I call the command mono --wapi=hps | wc -l each 30 second to build this graph! I will put my graphs on the internet to show everybody the problem! ___ Ce message et les ventuels documents joints peuvent contenir des informations confidentielles. Au cas oC il ne vous serait pas destin, nous vous remercions de bien vouloir le supprimer et en aviser immLes communications sur internet n'tant pas sscurises, l'intngrit de ce message n'est pas assur0e et la socit, mettrice ne peut rtre tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Jit and C# Compiler
On 10/05/06 Khaled A. K. Mohammed wrote: I am briefly describing the project below. The project will aim to improve the execution of CIL image on multicore processors. First step is to change the C# compiler to insert custom instructions into the managed binary (just like how the line #s are stored). These instructions will be parsed by JIT to pick valuable You may want to handle this at the IL code level, so that other languages than C# can be supported. You'd use Cecil or some other such library to load the compiled assembly, change the IL code and save it back. Depending on what you really want to do to the code, in most cases it might be enough to just change method calls to go through a runtime library you can write in C# that will dispatch the call to a pool of threads (obviously only for a selected subset of calls). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where do I start off??
On 10/05/06 Rafael Ferreira wrote: Well I want to work ON Mono and (not *with*) Mono,sorry for all the troubles again.I have around 3 months experience working on C# and ASP.Net.So http://ASP.Net.So where do i start developing?? [...] You should start here: http://mono-project.com/Contributing It's worth noting that if people looked at microsoft's code using ildasm, reflector or other means, they can't contribute to mono. So keep this in mind before investing time in writing code we can't accept (don't consider this relating to people participating in this thread, it's just something worth repeating once in a while:-). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] DataTable.WriteXml
Hi Patrick,
The patch looks fine, but it doesn't apply with the latest SVN. Can you
make a new patch and send it across.
Thanks
Nagappan
Patrick Earl wrote:
I've implemented the WriteXml method for System.Data.DataTable. Since
writing a table is similar to writing a DataSet, it leverages many of
the methods used to write DataSets. Included with the patch are a
successful unit test for the new WriteXml functionality and a failing
unit test for ReadXml, which has not yet been implemented. The patch
caused no regressions in the System.Data net_2_0 test suite.
The patch applies against the mcs/class/System.Data folder in the
latest SVN revision (66162 as of this message).
This is my first substantial contribution, so I'm happy to get
feedback on it. Thanks.
Patrick Earl
Index: Test/System.Data/ChangeLog
===
--- Test/System.Data/ChangeLog(revision 66162)
+++ Test/System.Data/ChangeLog(working copy)
@@ -1,3 +1,9 @@
+2006-09-28 Patrick Earl [EMAIL PROTECTED]
+
+ * DataTableReadWriteXml.cs: Added new tests for the DataTable's
+ ReadXml and WriteXml methods. These tests assume proper
+ functioning of the DataSet ReadXml and WriteXml methods.
+
2006-09-18 Boris Kirzner [EMAIL PROTECTED]
* DataViewTest.cs : fix compilation error.
Index: Test/System.Data/DataTableReadWriteXmlTest.cs
===
--- Test/System.Data/DataTableReadWriteXmlTest.cs (revision 0)
+++ Test/System.Data/DataTableReadWriteXmlTest.cs (revision 0)
@@ -0,0 +1,373 @@
+// Author:
+// Patrick Earl [EMAIL PROTECTED]
+//
+// Copyright (c) 2006
+//
+// 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.
+//
+
+#if NET_2_0
+using System;
+using System.Data;
+using System.IO;
+using System.Text.RegularExpressions;
+using System.Xml;
+using NUnit.Framework;
+
+namespace MonoTests.System.Data
+{
+[TestFixture]
+public class DataTableReadWriteXmlTest
+{
+void StandardizeXmlFormat(ref string xml)
+{
+XmlDocument doc = new XmlDocument();
+doc.LoadXml(xml);
+StringWriter sw = new StringWriter();
+doc.Save(sw);
+xml = sw.ToString();
+}
+
+void GenerateTestData(out DataSet ds,
+ out DataTable dtMainInDS,
+ out DataTable dtChildInDS,
+ out DataTable dtMain)
+{
+ds = new DataSet(MyDataSet);
+
+// Create a primary table and populate it with some data. Make a
+// copy of the primary table and put it into the dataset.
+dtMain = new DataTable(Main);
+dtMain.Columns.Add(new DataColumn(ID, typeof(int)));
+dtMain.Columns.Add(new DataColumn(Data, typeof(string)));
+
+DataRow row = dtMain.NewRow();
+row[ID] = 1;
+row[Data] = One;
+dtMain.Rows.Add(row);
+
+row = dtMain.NewRow();
+row[ID] = 2;
+row[Data] = Two;
+dtMain.Rows.Add(row);
+
+row = dtMain.NewRow();
+row[ID] = 3;
+row[Data] = Three;
+dtMain.Rows.Add(row);
+
+dtMainInDS = dtMain.Copy();
+ds.Tables.Add(dtMainInDS);
+
+// Create a child table. Make a copy of the child table and put
+// it into the dataset.
+dtChildInDS = new DataTable(Child);
+dtChildInDS.Columns.Add(new DataColumn(ID, typeof(int)));
+dtChildInDS.Columns.Add(new DataColumn(PID, typeof(int)));
+
Re: [Mono-dev] Mono 1.2 or 1.somethingelse?
I thinks 1.2 is ok.I calling it 2.0 would confuse the issue with .net 2.0 support.-- Sharique uddin Ahmed Farooqui(C++/C# Developer, IT Consultant)http://www.sharique.managefolio.com/ A revolution is about to begin.A world is about to change.And you and me are the initiator. On 10/4/06, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Michael Schurter escribió: Miguel de Icaza wrote: I would even go as far as saying that we could feel confident that this could be called Mono 2.0, but 2.0 would have the unfortunate effect of confusing people regarding our .net 2.0 support. Agreed!I also agree. So am thinking that maybe we could call this Mono 1.5, or if we plan on keeping the even/odd release numbers from the kernel that we could call this Mono 1.6 or 1.8 Opinions? 1.2 seems fine to me.I don't think people really care as long as new release number old release number.Skipping version numbers may make developers feel better, but it leaves users scratching their heads about where 1.2-1.4 went. Also, 1.5 could be interpreted to mean halfway to .NET 2.0, which is in no way accurate. I agree with Michael. BTW, can we measure approximately, in apercentage, the current implementation of the 2.0 profile?Regards,Andrés[ knocte ]--___ Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://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] System.dll few patches for review
Care to explain why? I'm aware that Invariant will be (invariant-culture) sensitive, however it IMHO would fix the bug. I also agree that using String.Compare with OrdinalIgnoreCase would be the best option, however unfortunatelly that is .Net 2.0 only. String.CompareOrdinal() is obviously obviously a no-go because it would be case-sensitive and as I already wrote CompareOptions are 2.0 only. Happy hacking Andreas P.S. If I'd design a new .Net Framework the first thing would be to create two Classes: (System)String and LanguageString. You are still wrong :-) InvariantCulture still causes culture sensitive comparison. Use String.CompareOrdinal() or CompareOptions.Ordinal instead. Atsushi Eno Andreas Nahr wrote: Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Because there are characters that are ignored even in invariant comparison. Well, I agree that instead was not proper here. It should be additionally. Atsushi Eno Andreas Nahr wrote: Care to explain why? I'm aware that Invariant will be (invariant-culture) sensitive, however it IMHO would fix the bug. I also agree that using String.Compare with OrdinalIgnoreCase would be the best option, however unfortunatelly that is .Net 2.0 only. String.CompareOrdinal() is obviously obviously a no-go because it would be case-sensitive and as I already wrote CompareOptions are 2.0 only. Happy hacking Andreas P.S. If I'd design a new .Net Framework the first thing would be to create two Classes: (System)String and LanguageString. You are still wrong :-) InvariantCulture still causes culture sensitive comparison. Use String.CompareOrdinal() or CompareOptions.Ordinal instead. Atsushi Eno Andreas Nahr wrote: Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] nant console output doubled since corlib update
Gonzalo Paniagua Javier wrote: On Thu, 2006-10-05 at 15:50 -0500, Michael Schurter wrote: snip Now all of the console output from nant 0.85rc4 is doubled (prints twice). A simple HelloWorld program's output works as expected, so it might be a problem with nant. snip There's a patch for nant to fix the double output issue. -Gonzalo I've discussed this with Gonzalo and Gert off list, so to keep everyone informed I'll wrap up this thread: * Bug is a nant 0.85rc4 issue (I'll stop cluttering this list!) * Patch is in nant's cvs head, and Gert should be posting a new nightly binary soon. * You can workaround this issue by redirecting nant's output to a file using nant build output.log or a similar command. -- Michael Schurter Synthesys Solutions ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WAPI Handle Leaks
Hello, I experienced the same problem as you... I run mod-mono-server on my productions server, with very big applications (more than 100 aspx pages). I see that threads handles are always growing... (even when there's no request to the server!!!) I've sent graphs to Gonzalo to show my problem but i've no answer... I will put my graphs on the internet to show everybody the problem! I do not think this is a bug that Gonzalo can fix, this seems like an io-layer problem. You might want to include the output of mono --wapi=hps in a bug report. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
