[Mono-dev] Regression between 1.2.4 and 1.2.5 Preview 5
Getting a WSDL service description for one of our services worked for 1.2.4. When refreshing the web reference on 1.2.5 preview 5, SharpDevelop gives the exception shown below. I have compiled mono from source, so if I can be of assistance in solving this, let me know. Patrick SharpDevelop Version : 2.2.0.2595 .NET Version : 2.0.50727.832 OS Version : Microsoft Windows NT 5.1.2600 Service Pack 2 Current culture : English (United States) (en-US) Working Set Memory : 153748kb GC Heap Memory : 63585kb Exception thrown: System.InvalidOperationException: The document at the url http://www.dril.com:9090/FSWebServices/FSUserService/FSUserService.asmx was not recognized as a known document type. The error message from each known type may help you fix the problem: - Report from ' http://www.dril.com:9090/FSWebServices/FSUserService/FSUserService.asmx' is 'The document format is not recognized (the content type is 'text/html; charset=utf-8').'. - Report from 'DISCO Document' is 'There was an error downloading ' http://www.dril.com:9090/lt;%25=Request.FilePath%25?disco'.'. - The request failed with HTTP status 404: Not Found. - Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=utf-8').'. - Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=utf-8').'. at System.Web.Services.Discovery.DiscoveryClientProtocol.DiscoverAny(String url) at ICSharpCode.SharpDevelop.Project.Commands.RefreshWebReference.DiscoverWebServices(String url) at ICSharpCode.SharpDevelop.Project.Commands.RefreshWebReference.Run() at ICSharpCode.Core.MenuCommand.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message m) at System.Windows.Forms.ScrollableControl.WndProc(Message m) at System.Windows.Forms.ToolStrip.WndProc(Message m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CruiseControl.Net on linux and threading problems
Without further investigation I would assume this was related to the thread handle issue reported a number of times in the past. One of the bug reports is here: http://bugzilla.ximian.com/show_bug.cgi?id=79060 We have resorted to restarting our server (and cleaning up the wapi files) nightly to work around the bug. Patrick On 2/5/07, Leszek Ciesielski [EMAIL PROTECTED] wrote: Hi, I am using CruiseControl.Net on a linux machine running mono, and after 3 or 4 days of running the process is unable to start further threads. This works fine on mono ms.net on windows. I have inspected the code and I do not see any obvious errors - all threads seem to be Aborted/Joined after they are no longer needed, this is done by wrapping classes that create them in using and shutting down the threads in Dispose calls. It seems to be a problem with mono. Should I file a bug with mono or with cc.net? Or both? CC.Net reports: 2007-02-04 03:42:28,053 [Projectname:ERROR] INTERNAL ERROR: Thread creation failed. -- System.SystemException: Thread creation failed. at System.Threading.Thread.Start () [0x0] at ThoughtWorks.CruiseControl.Core.Util.ProcessReader..ctor (System.IO.TextReader stream) [0x0] at ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor+RunnableProcess.Run () [0x0] at ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.Execute (ThoughtWorks.CruiseControl.Core.Util.ProcessInfo processInfo) [0x0] at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute (ThoughtWorks.CruiseControl.Core.Util.ProcessInfo processInfo) [0x0] at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications (ThoughtWorks.CruiseControl.Core.Util.ProcessInfo info, DateTime from, DateTime to) [0x0] at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Cvs.GetModifications (IIntegrationResult from, IIntegrationResult to) [0x0] at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModificationsWithLogging (ISourceControl sc, IIntegrationResult from, IIntegrationResult to) [0x0] at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications (ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild) [0x0] at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications (IIntegrationResult from, IIntegrationResult to) [0x0] at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate (ThoughtWorks.CruiseControl.Remote.IntegrationRequest request) [0x0] at ThoughtWorks.CruiseControl.Core.Project.Integrate (ThoughtWorks.CruiseControl.Remote.IntegrationRequest request) [0x0] at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate () [0x0] Attached is my attempt at creating a simplified test case. Regards, Leszek -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.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] Mono.Data.SqliteClient ADO.NET 2.0 - new implementation
I'm glad to see Mono supporting the provider from Robert Simpson. It seems to be of high quality and actively maintained. I'm curious whether the encryption support in the provider will be made cross-platform if committed to mono. I would personally find such support beneficial. Patrick On 1/31/07, Marek Habersack [EMAIL PROTECTED] wrote: Hello, Attached is a new ADO.NET 2.0 provider for Sqlite3, adapted from http://sqlite-dotnet2.sourceforge.net/. Initially I thought the changes would be few, but then it turned out a more extensive adaptation was in order. I have tested the new stuff with f-spot which works nearly ok, except for an issue which turned out to be a bug in f-spot code (src/TagStore.cs:312 calls command.Dispose() and then goes on to reuse the command, which causes a problem since command.Connection is cleared by command.Dispose()). Please apply the patch to a copy of mono svn head and test on whatever application you have that uses Sqlite. A point to note - the new implementation does NOT support sqlite database format version 2! If your database is in that format, you need to convert it to format 3 (dump with sqlite 2.x and undump with sqlite3) prior to testing the code. Please let me know about any and all problems/issues you encouter while testing. thanks in advance for your time, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-platform fsync()
If I wanted to add this functionality to the mono class library so no p/invokes are required, does anyone have any suggestions where it should be added? I've seen most new functionality added to Mono.* classes, but I don't see anything like Mono.IO. Are there any guidelines on where something like this might go? Patrick On 1/9/07, Robert Jordan [EMAIL PROTECTED] wrote: On MS.NET and Mono for Windows, the proper function is WIN32's FlushFileBuffers()that can be called via p/invoke from kernel32.dll either on FileStream.Handle, or (.NET 2.0) on FileStream.SafeFileHandle. On Linux, FlushFileBuffers() is provided by Mono's WAPI layer that calls fsync(2) internally, but I don't know how it can be called from managed code. Maybe like this (untested): [DllImport(__Internal)] public static bool FlushFileBuffers (IntPtr handle); For .NET 2.0: [DllImport(__Internal)] public static bool FlushFileBuffers (SafeFileHandle handle); ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cross-platform fsync()
Greetings all. I've recently run into the need for a cross platform fsync() call. As far as I know, all of the flavors of unix that mono supports provide the fsync call themselves. On windows, there is a _commit() function that does the same thing. It seems like the underlying platform support is there, but I'm not sure how to bring that back up into the .net world so we can, for example, perform some sort of flush to disk operation on a FileStream. Suggestions? Ideas? Patrick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WAPI Handle Leaks
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
[Mono-dev] [PATCH] System.Transactions key is wrong
The System.Transactions key should be b77a5c561934e089. The following patch changes the key file to the same file that other assemblies with the same name use. I don't really know what that JVM stuff is, but it seemed to be present in the other cases. After applying this patch, my system properly loaded an ADO.NET 2 provider compiled on windows. Patrick Index: class/System.Transactions/Assembly/AssemblyInfo.cs === --- class/System.Transactions/Assembly/AssemblyInfo.cs (revision 66235) +++ class/System.Transactions/Assembly/AssemblyInfo.cs (working copy) @@ -45,7 +45,9 @@ [assembly: NeutralResourcesLanguage (en-US)] [assembly: AssemblyDelaySign (true)] -[assembly: AssemblyKeyFile (../msfinal.pub)] +#if !TARGET_JVM +[assembly: AssemblyKeyFile (../ecma.pub)] +#endif #if NET_2_0 [assembly: AssemblyCompany (MONO development team)] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] DataTable.WriteXml
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)));
+dtChildInDS.Columns.Add(new DataColumn(ChildData,
typeof(string)));
+
+row = dtChildInDS.NewRow();
+row[ID] = 1;
+row[PID] = 1;
+row[ChildData] = Parent1Child1;
+dtChildInDS.Rows.Add(row);
+
+row = dtChildInDS.NewRow();
+row[ID
Re: [Mono-dev] Thread Pool WAPI Ref Problems
Putting one unpleasant hack in the source eliminated the leaking wapi thread handles in the test application I was using. However, when running the same code on the production server, there are still many thread handles leaking from other places. It seems there is some systematic problem with leaking handles. Is it possible that a solution might be created that takes care of the wapi handles in a more automatic manner? Perhaps certain handles could be freed automatically if a flag is set on creation. Along the same lines, could somebody explain what the relationship is between threads created by mono_thread_create and the garbage collector? What happens to those MonoThread objects? Where are those handles meant to be freed? I saw a post that at some point there was the intention to move objects away from the garbage collector and have them managed internally. Is this still the intention? I assume that if references to handles can escape from the internal code to the managed space, we must then allow the gc to deal with closing those handles. Is that correct? Thanks for the clarification on this. Patrick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Thread Pool WAPI Ref Problems
Hi. I've been trying to track what might be causing the issue in the
following bug:
http://bugzilla.ximian.com/show_bug.cgi?id=79060
It seems to be some problem with wapi refs in the threadpool. In any
case, though I don't have a good understanding of how everything
connects, I did notice one strange thing when I was poking through the code.
In the start_thread_or_queue method, there is a domain variable assigned
that is never used. Is there a problem here?
static void
start_thread_or_queue (MonoAsyncResult *ares)
{
int busy, worker;
MonoDomain *domain;
busy = (int) InterlockedCompareExchange (busy_worker_threads,
0, -1);
worker = (int) InterlockedCompareExchange (mono_worker_threads,
0, -1);
if (worker = ++busy
worker mono_max_worker_threads) {
InterlockedIncrement (mono_worker_threads);
InterlockedIncrement (busy_worker_threads);
HERE: domain = ((MonoObject *) ares)-vtable-domain;
mono_thread_create (mono_get_root_domain (),
async_invoke_thread, ares);
} else {
append_job (mono_delegate_section, async_call_queue,
ares);
ReleaseSemaphore (job_added, 1, NULL);
}
}
I do know that this particular method is called for the leaked handles.
Thanks.
Patrick Earl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread Pool WAPI Ref Problems
Is it correct to assume that wapi handles for threads should stick around until sometime after the thread finishes executing? If so, it seems that the leaking wapi handles (created in the thread pool) are caused by missing code in mono/metadata/threads.c:start_wrapper() function. After looking through all the code that occurs after the main thread function is called, I don't see any place that the wapi handle would be released. Am I missing something, or could this be the problem? Patrick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Static Variables
Seeing the mono_class_static_field_address function, I assumed that there might be an initial lookup for the address, even if the value itself was assigned directly later on. Is this not true? Perhaps even the lookup happens in a direct manner in the jit machine? I will try and produce a small test case. It's a sizeable chunk of code, but hopefully a small test case will produce the same results. I'm happy to insert debugging code if desired on my system as well, though I realize that it's not particularly easy to work that way. Patrick Robert Jordan writes: [snip snip snip] These (at least mono_field_static_set_value) are never called by JIT code. They are part of the metadata API and are used by the runtime code and maybe by System.Reflection. The JIT code is accessing the fields directly. About your issue: I was not able to reproduce it, even with multiple domains. Please provide (attach it to the bug entry) *exactly* the same test case which failed on your machine. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Static Variables
Hi all. I'm trying to track down a bug relating to static variables. You can see what the bug is all about here: http://bugzilla.ximian.com/show_bug.cgi?id=79211 I can easily examine the call that attempts to retrieve the value for ipv4Supported. However, I can't find the call where the variable is set. I can see it being set in the C# code in Socket.cs. I have debug code there that indicates that it is indeed being set. It's being set in the same domain, but for some reason, the values are different in the C# code and in the mono internal calls. Any suggestions on how I might proceed? I've checked: metadata/object.c: mono_field_static_set_value And: mini/jit-icalls.c: mono_class_static_field_address But neither seem to be called for a field with the name of ipv4Supported. The variables seem to be initialized properly (they contain -1 when the runtime lookup occurs), but after 1 is assigned to them, the runtime system still thinks they have -1 in them. Any hints on how to proceed with debugging or how this issue might be fixed are much appreciated. Thanks. Patrick Earl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
