Re: [Mono-dev] Debugger crashes while debugging ASP.NET app
El dj 13 de 01 de 2011 a les 13:21 -0800, en/na passiday va escriure: Hello, I'm experiencing this weird debugger crashing. Spent now about 4 hours trying to work it out, and no luck. I'm really betting on this mailing list... So, this problem is there since I have installed MonoDevelop on my Ubuntu 10.10 64bit. I am trying to debug ASP.NET application - setting breakpoints, checking watches, stepping through the code line by line. So, I can successfully build my app, and run it in debug mode, it hits the first breakpoint, I can check the watches. Bud when I hit the Step over, the app immediately crashes. No info is dumped in Application Output pad. Funny thing is that very rarely it doesn't crash and lets me step over several lines, until the next breakpoint is hit and then crashes again, when trying to step further. Very annoying. Basically I am limited to one breakpoint for debugging, or to use awkward tools like dumping the debug variables to file or database. Does somebody have any clue, what's going on here? I know I am giving very little information on this crash. Maybe you can suggest how I can extract more information to supply to the case. Try running MonoDevelop from a terminal, and see which output you get. Also make sure you have the latest MonoDevelop and Mono. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Debugger crashes while debugging ASP.NET app
Hello Lluis, Try running MonoDevelop from a terminal, and see which output you get. Also make sure you have the latest MonoDevelop and Mono. The MonoDevelop and Mono was fetched from depositories, using synaptic, on 13th of January. My colleague installed MonoDevelop on his Kubuntu, and experiences no problems whatsoever. So, this is something connected with my system. Below is the console output. Not too much happens in the console, when the debugger is crashing. But as there are some errors upon running the monodevelop, and building and running the app, maybe they are somehow connected with this crash? Maybe there is some debugger log file, where there could be more info about what is happening? * Console output, when stating up the MonoDevelop: WARNING: Cannot find Mozilla directory containing libgtkembedmoz.so. Some Addins may not be able to function. Please set MOZILLA_FIVE_HOME to your Mozilla directory. WARNING [2011-01-14 15:48:18Z]: Error creating composed icon gtk-execute___asm0__debug-overlay-22.png__SmallToolbar at size SmallToolbar. Icon __asm0__debug-overlay-22.png__SmallToolbar is 22x22, expected 18x18. ERROR [2011-01-14 15:48:18Z]: GdkPixbuf-Critical: gdk_pixbuf_composite: assertion `dest_x = 0 dest_x + dest_width = dest-width' failed Stack trace: at Gdk.Pixbuf.Composite(Gdk.Pixbuf dest, Int32 dest_x, Int32 dest_y, Int32 dest_width, Int32 dest_height, Double offset_x, Double offset_y, Double scale_x, Double scale_y, InterpType interp_type, Int32 overall_alpha) at MonoDevelop.Ide.ImageService.MergeIcons(Gdk.Pixbuf icon1, Gdk.Pixbuf icon2) at MonoDevelop.Ide.ImageService.GetComposedIcon(System.String[] ids, IconSize size) at MonoDevelop.Ide.ImageService.InternalGetStockId(Mono.Addins.RuntimeAddin addin, System.String filename, IconSize size) at MonoDevelop.Ide.ImageService.LoadStockIcon(MonoDevelop.Ide.Extensions.StockIconCodon iconCodon) at MonoDevelop.Ide.ImageService.EnsureStockIconIsLoadedm__11C(MonoDevelop.Ide.Extensions.StockIconCodon i) at System.Collections.Generic.List`1[[MonoDevelop.Ide.Extensions.StockIconCodon, MonoDevelop.Ide, Version=2.4.0.0, Culture=neutral, PublicKeyToken=null]].ForEach(System.Action`1 action) at MonoDevelop.Ide.ImageService.EnsureStockIconIsLoaded(System.String stockId, IconSize size) at MonoDevelop.Ide.ImageService.ImageServicem__11A(System.String stockId) at MonoDevelop.Core.IconId.get_Name() at MonoDevelop.Core.IconId.op_Implicit(IconId icon) at MonoDevelop.Components.Commands.CommandToolButton.Update(MonoDevelop.Components.Commands.CommandInfo cmdInfo) at MonoDevelop.Components.Commands.CommandToolButton.MonoDevelop.Components.Commands.ICommandUserItem.Update(MonoDevelop.Components.Commands.CommandTargetRoute targetRoute) at MonoDevelop.Components.Commands.CommandToolButton.OnParentSet(Gtk.Widget parent) at Gtk.Widget.parentset_cb(IntPtr widget, IntPtr previous_parent) at Gtk.Container.gtksharp_container_base_add(IntPtr , IntPtr ) at Gtk.Container.OnAdded(Gtk.Widget widget) at MonoDevelop.Components.DockToolbars.DockToolbar.OnAdded(Gtk.Widget w) at Gtk.Container.added_cb(IntPtr container, IntPtr widget) at Gtk.Container.gtk_container_add(IntPtr , IntPtr ) at Gtk.Container.Add(Gtk.Widget widget) at MonoDevelop.Components.Commands.CommandManager.CreateToolbar(System.String id, MonoDevelop.Components.Commands.CommandEntrySet entrySet, System.Object initialTarget) at MonoDevelop.Components.Commands.CommandManager.CreateToolbar(System.String id, MonoDevelop.Components.Commands.CommandEntrySet entrySet) at MonoDevelop.Components.Commands.CommandManager.CreateToolbarSet(System.String addinPath) at MonoDevelop.Ide.Gui.DefaultWorkbench.InitializeWorkspace() at MonoDevelop.Ide.Gui.Workbench.Initialize(IProgressMonitor monitor) at MonoDevelop.Ide.IdeApp.Initialize(IProgressMonitor monitor) at MonoDevelop.Ide.IdeStartup.Run(System.String[] args) at MonoDevelop.Startup.MonoDevelopMain.Main(System.String[] args) ERROR [2011-01-14 15:48:18Z]: Error updating Welcome Page content. System.Xml.XmlException: Document element did not appear. file:///home/pavils/.config/MonoDevelop/news.xml Line 1, position 1. at Mono.Xml2.XmlTextReader.Read () [0x0] in filename unknown:0 at System.Xml.XmlTextReader.Read () [0x0] in filename unknown:0 at System.Xml.XmlDocument.ReadNodeCore (System.Xml.XmlReader reader) [0x0] in filename unknown:0 at System.Xml.XmlDocument.ReadNode (System.Xml.XmlReader reader) [0x0] in filename unknown:0 at System.Xml.XmlDocument.Load (System.Xml.XmlReader xmlReader) [0x0] in filename unknown:0 at MonoDevelop.WelcomePage.WelcomePageView.GetUpdatedXmlDocument () [0x0] in filename unknown:0 * When building and running ASP.NET web app: ERROR [2011-01-14 15:48:38Z]: Type 'Module' loaded more than once ERROR [2011-01-14 15:48:38Z]: Type 'Module' loaded more than once ERROR [2011-01-14 15:48:38Z]: Type
[Mono-dev] WCF in Mono 2.6.7
I am having trouble getting WCF working on Mono in Suse Linux 11.3
I have the client as follow:
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
EndpointAddress address = new
EndpointAddress(http://localhost:5800/DataUploader;);
ChannelFactoryIDataUploader channel = new
ChannelFactoryIDataUploader(binding, address);
IDataUploader uploader = channel.CreateChannel();
try
{
uploader.Upload(File.Open(@G:\anthem-1.5.2.zip,
FileMode.Open, FileAccess.Read));
Console.WriteLine(File uploaded to the server);
Console.ReadLine();
}
catch (Exception ex)
{
Console.Write(ex.Message);
Console.ReadLine();
}
finally
{
((IClientChannel)uploader).Close();
}
I have the following interface:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
Now the service is as follow on DataUploader.cs:
class DataUploader : IDataUploader
{
#region IDataUploader Members
public void Upload(Stream data)
{
string xmlFile = @c:\temp\uploadedfile + .zip;
using (FileStream fs = new FileStream(xmlFile, FileMode.Create))
{
int bufferSize = 1 * 1024 * 1024; // 1MB buffer
byte[] buffer = new byte[bufferSize];
int bytes;
while ((bytes = data.Read(buffer, 0, bufferSize)) 0)
{
fs.Write(buffer, 0, bytes);
fs.Flush();
}
}
}
#endregion
}
Now on IDataUploader.cs:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
On the main.cs I have:
public static void Main (string[] args)
{
ServiceHost host = new
ServiceHost(typeof(DataUploader));
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
host.AddServiceEndpoint(typeof(IDataUploader), binding, new
Uri(http://localhost:5800/DataUploader;));
ServiceBehaviorAttribute attribute =
(ServiceBehaviorAttribute)host.Description.Behaviors[typeof(ServiceBehaviorAttribute)];
attribute.ConcurrencyMode = ConcurrencyMode.Multiple;
attribute.InstanceContextMode = InstanceContextMode.Single;
attribute.IncludeExceptionDetailInFaults = true;
ServiceThrottlingBehavior throttling = new
ServiceThrottlingBehavior();
throttling.MaxConcurrentSessions = 24;
throttling.MaxConcurrentCalls = 24;
host.Description.Behaviors.Add(throttling);
host.Open();
Console.WriteLine(Service Hosted ...);
Console.ReadKey();
host.Close();
}
I have both client and service running on the same system. I get an error:
Object reference not set to an instance of an object error. When I run a
client on a windows system and the service on the linux system I get bad
request(400) error. Can someone help me understand what I am missing?
--
View this message in context:
http://mono.1490590.n4.nabble.com/WCF-in-Mono-2-6-7-tp3217763p3217763.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Finalizers in CriticalHandle
Hi all
I'm currently debugging an issue that appears to be caused by the
non-release of unmanaged resources in CriticalHandle. I'm using the git
master branch.
In CriticalHandle.cs:
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
~CriticalHandle ()
{
Dispose (false);
}
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
protected virtual void Dispose (bool disposing)
{
if (_disposed)
return;
_disposed = true;
if (IsInvalid)
return;
if (disposing == true !IsInvalid){
if (!ReleaseHandle ()) {
GC.SuppressFinalize (this);
} else {
// Failed in release...
}
}
}
Unless I'm missing something, this looks to me that when the
CriticalHandle object is finalized, the unmanaged resources won't be
released: ReleaseHandle() isn't called.
Is this a bug?
- Dick
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for StopRoutingHandler - stop handling routes instead of throwing
Hi all,
noticed that adding routes using StopRoutingHandler() throws
NotSupportedExceptions instead of simply ceasing further processing in the
UrlRoutingModule.
Attached is the patch I wrote to change that behavior on master branch,
accompanied with a unit test.
Best,
Damir
From 6917f50523363e4b517d00490cf2e7ffc5d9ccbf Mon Sep 17 00:00:00 2001
From: Damir Simunic damir.simu...@wa-research.ch
Date: Fri, 14 Jan 2011 15:32:13 +0100
Subject: [PATCH] Ignore routes with StopRoutingHandler instead of throwing
---
.../System.Web.Routing/UrlRoutingModule.cs |3 +++
.../System.Web.Routing/UrlRoutingModuleTest.cs | 11 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git
a/mcs/class/System.Web.Routing/System.Web.Routing/UrlRoutingModule.cs
b/mcs/class/System.Web.Routing/System.Web.Routing/UrlRoutingModule.cs
index cf8465e..c1a5b2d 100644
--- a/mcs/class/System.Web.Routing/System.Web.Routing/UrlRoutingModule.cs
+++ b/mcs/class/System.Web.Routing/System.Web.Routing/UrlRoutingModule.cs
@@ -119,6 +119,9 @@ namespace System.Web.Routing
if (rd.RouteHandler == null)
throw new InvalidOperationException (No
IRouteHandler is assigned to the selected route);
+ if (rd.RouteHandler is StopRoutingHandler)
+ return; //stop further processing
+
var rc = new RequestContext (context, rd);
IHttpHandler http = rd.RouteHandler.GetHttpHandler (rc);
diff --git
a/mcs/class/System.Web.Routing/Test/System.Web.Routing/UrlRoutingModuleTest.cs
b/mcs/class/System.Web.Routing/Test/System.Web.Routing/UrlRoutingModuleTest.cs
index 7357f1a..a55d911 100644
---
a/mcs/class/System.Web.Routing/Test/System.Web.Routing/UrlRoutingModuleTest.cs
+++
b/mcs/class/System.Web.Routing/Test/System.Web.Routing/UrlRoutingModuleTest.cs
@@ -155,6 +155,17 @@ namespace MonoTests.System.Web.Routing
#endif
// it internally stores the handler
}
+
+ [Test]
+ public void PostResolveRequestCacheStopRoutingHttpHandler ()
+ {
+ var m = new UrlRoutingModule ();
+ RouteTable.Routes.Add (new MyRoute (foo/bar, new
StopRoutingHandler ()));
+ var hc = new HttpContextStub3 (~/foo/bar,
String.Empty, apppath, false);
+ m.PostResolveRequestCache (hc);
+ Assert.IsNull (hc.RewrittenPath, StopRoutingHandler
should stop before the path is rewritten);
+ }
+
[Test]
[Ignore (looks like RouteExistingFiles ( = false) does not
affect... so this test needs more investigation)]
--
1.7.3.3
StopRouteHandler.patch
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't compile mono 2.8 for ARM Linux 2.6.24
This is already fixed. -g On 2011-01-14, at 12:15 AM, J.P. wrote: I cannot compile current mono in git. See below. AOT [basic] mscorlib.dll.so /bin/sh: line 1: 3231 Aborted MONO_PATH='./../../class/lib/basic/' /skcomms/src/mono/git/mono/runtime/mono-wrapper --aot=bind-to-runtime-version --debug ./../../class/lib/basic//mscorlib.dll basic_aot.log 21 /skcomms/src/mono/git/mono/libtool: line 6823: LC_CTYPE: command not found /skcomms/src/mono/git/mono/libtool: line 6823: LC_COLLATE: command not found /skcomms/src/mono/git/mono/libtool: line 6823: LC_MESSAGES: command not found Mono Ahead of Time compiler - compiling assembly /skcomms/src/mono/git/mono/mcs/class/lib/basic/mscorlib.dll * Assertion: should not be reached at boehm-gc.c:1150 Stacktrace: Native stacktrace: /skcomms/src/mono/git/mono/mono/mini/mono [0x4a831d] /lib64/libpthread.so.0 [0x38b300e7c0] /lib64/libc.so.6(gsignal+0x35) [0x38b2430265] /lib64/libc.so.6(abort+0x110) [0x38b2431d10] /skcomms/src/mono/git/mono/mono/mini/mono [0x5ee032] /skcomms/src/mono/git/mono/mono/mini/mono [0x5ee20a] /skcomms/src/mono/git/mono/mono/mini/mono [0x5bd3ea] /skcomms/src/mono/git/mono/mono/mini/mono [0x4c5ac1] /skcomms/src/mono/git/mono/mono/mini/mono [0x4c6d91] /skcomms/src/mono/git/mono/mono/mini/mono [0x42cdcd] /skcomms/src/mono/git/mono/mono/mini/mono [0x489cbc] /skcomms/src/mono/git/mono/mono/mini/mono [0x493be8] /skcomms/src/mono/git/mono/mono/mini/mono(mono_main+0x1449) [0x4845a9] /lib64/libc.so.6(__libc_start_main+0xf4) [0x38b241d994] /skcomms/src/mono/git/mono/mono/mini/mono(realloc+0x389) [0x423c09] Debug info from gdb: [Thread debugging using libthread_db enabled] [New Thread 0x2ad55d083910 (LWP 3231)] [New Thread 0x44c1b940 (LWP 3310)] [New Thread 0x44a07940 (LWP 3309)] [New Thread 0x44006940 (LWP 3307)] [New Thread 0x43605940 (LWP 3306)] [New Thread 0x42c04940 (LWP 3305)] [New Thread 0x42203940 (LWP 3304)] [New Thread 0x41802940 (LWP 3303)] [New Thread 0x40cb1940 (LWP 3302)] 0x0038b300d5cb in read () from /lib64/libpthread.so.0 9 Thread 0x40cb1940 (LWP 3302) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x41802940 (LWP 3303) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x42203940 (LWP 3304) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x42c04940 (LWP 3305) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x43605940 (LWP 3306) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x44006940 (LWP 3307) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x44a07940 (LWP 3309) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x44c1b940 (LWP 3310) 0x0038b300c9b1 in sem_wait () from /lib64/libpthread.so.0 * 1 Thread 0x2ad55d083910 (LWP 3231) 0x0038b300d5cb in read () from /lib64/libpthread.so.0 Thread 9 (Thread 0x40cb1940 (LWP 3302)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x0) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x41802940 (LWP 3303)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x1) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x42203940 (LWP 3304)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x2) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x42c04940 (LWP 3305)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in
Re: [Mono-dev] Finalizers in CriticalHandle
I suppose it is. Does .NET call Release on finalizer?
On Fri, Jan 14, 2011 at 4:30 PM, Dick Porter dpor...@codicesoftware.comwrote:
Hi all
I'm currently debugging an issue that appears to be caused by the
non-release of unmanaged resources in CriticalHandle. I'm using the git
master branch.
In CriticalHandle.cs:
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
~CriticalHandle ()
{
Dispose (false);
}
[ReliabilityContract (Consistency.WillNotCorruptState,
Cer.Success)]
protected virtual void Dispose (bool disposing)
{
if (_disposed)
return;
_disposed = true;
if (IsInvalid)
return;
if (disposing == true !IsInvalid){
if (!ReleaseHandle ()) {
GC.SuppressFinalize (this);
} else {
// Failed in release...
}
}
}
Unless I'm missing something, this looks to me that when the
CriticalHandle object is finalized, the unmanaged resources won't be
released: ReleaseHandle() isn't called.
Is this a bug?
- Dick
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem when running winforms app on arm processor
PLEA FOR URGENT HELP Almost 7 weeks and not a single response on this except to confirm that another is also having the problem. Is there no one that can shed light on what is going on here? I cannot run any winforms apps on an arm processor without hitting the assertion in tramp-arm.c. I am willing to help in any way I can, but I'm not an assembly language programmer, nor am I familiar with reasons behind the patching that is going on in the arm trampoline, so I really need some assistance. Thank You. Matt From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Matt Johnson Sent: Monday, January 03, 2011 10:24 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Problem when running winforms app on arm processor No, I have no resolution yet. I have simplified my winforms test application such that it is a single form with a single text hello world label and no code logic whatsoever. It crashes in the exact same manner. One point I am unclear on is that I read in some old posts that the thumb instruction set is not supported. I am not compiling with thumb enabled, but I am using a toolchain that targets armv4t instead of straight armv4. I actually found it very difficult to even find an non-t toolchain out there - I'd have to compile one from scratch if this is the problem. I don't see how it could be though. Especially since it is only winforms apps that are failing. Can someone with some expertise with the arm trampoline please chime in here? It is fairly urgent. Thanks, Matt From: Jae Kim [mailto:jkim0...@gmail.com] Sent: Friday, December 17, 2010 10:52 AM To: mj1856 Subject: Re: [Mono-dev] Problem when running winforms app on arm processor Hi Matt, Did you ever resolve this? I'm experiencing the same problem. Thanks, Jae On Mon, Nov 29, 2010 at 7:44 PM, mj1856 mj1...@hotmail.com wrote: I have cross compiled mono 2.8 with libgdiplus for the s3c2410 processor I am running. It is an arm920t (armv4t architecture). I use scratchbox with a recent codesourcery toolchain. I have two test applications that I wrote in visual studio targeting .net 2.0. The first is a console app with a basic Hello world. It works perfectly. The second is a winforms app with a single form that has a simple label that gets updated with a timer control to show the current date and time. (basically a digital clock). Running it, I get the following error: * Assertion: should not be reached at tramp-arm.c:48 Checking /mono/mini/tramp-arm.c, the function in question is mono_arch_patch_callsite, which has two blocks of code, where one of them is supposed to run. I'm not sure exactly what it's checking here, but neither block gets executed, so it hits the assertion. Can anyone shed some light on what might be the problem? One note that may or may not be of interest, but because the codesourcery toolchain is multilib, I have to specify -march=armv4t on the CFLAGS passed to configure mono. This appears to be working, as my console app works fine. I do have a running X server, which I've tested with other native apps, so I know at least that part is functional. Thanks, Matt -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-when-running-winforms-app-on-arm-p rocessor-tp3064820p3064820.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem when running winforms app on arm processor
Matt, We cannot replicate this problem, so you'll need to help narrow down the field. Can you get the gdb output of x/6i code-16 when gdb is at tramp-arm.c line 48? Thanks -g On 2011-01-14, at 11:28 AM, Matt Johnson wrote: PLEA FOR URGENT HELP Almost 7 weeks and not a single response on this except to confirm that another is also having the problem. Is there no one that can shed light on what is going on here? I cannot run any winforms apps on an arm processor without hitting the assertion in tramp-arm.c. I am willing to help in any way I can, but I’m not an assembly language programmer, nor am I familiar with reasons behind the patching that is going on in the arm trampoline, so I really need some assistance. Thank You. Matt From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Matt Johnson Sent: Monday, January 03, 2011 10:24 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Problem when running winforms app on arm processor No, I have no resolution yet. I have simplified my winforms test application such that it is a single form with a single text “hello world” label and no code logic whatsoever. It crashes in the exact same manner. One point I am unclear on is that I read in some old posts that the thumb instruction set is not supported. I am not compiling with thumb enabled, but I am using a toolchain that targets armv4t instead of straight armv4. I actually found it very difficult to even find an “non-t” toolchain out there – I’d have to compile one from scratch if this is the problem. I don’t see how it could be though. Especially since it is only winforms apps that are failing. Can someone with some expertise with the arm trampoline please chime in here? It is fairly urgent. Thanks, Matt From: Jae Kim [mailto:jkim0...@gmail.com] Sent: Friday, December 17, 2010 10:52 AM To: mj1856 Subject: Re: [Mono-dev] Problem when running winforms app on arm processor Hi Matt, Did you ever resolve this? I'm experiencing the same problem. Thanks, Jae On Mon, Nov 29, 2010 at 7:44 PM, mj1856 mj1...@hotmail.com wrote: I have cross compiled mono 2.8 with libgdiplus for the s3c2410 processor I am running. It is an arm920t (armv4t architecture). I use scratchbox with a recent codesourcery toolchain. I have two test applications that I wrote in visual studio targeting .net 2.0. The first is a console app with a basic Hello world. It works perfectly. The second is a winforms app with a single form that has a simple label that gets updated with a timer control to show the current date and time. (basically a digital clock). Running it, I get the following error: * Assertion: should not be reached at tramp-arm.c:48 Checking /mono/mini/tramp-arm.c, the function in question is mono_arch_patch_callsite, which has two blocks of code, where one of them is supposed to run. I'm not sure exactly what it's checking here, but neither block gets executed, so it hits the assertion. Can anyone shed some light on what might be the problem? One note that may or may not be of interest, but because the codesourcery toolchain is multilib, I have to specify -march=armv4t on the CFLAGS passed to configure mono. This appears to be working, as my console app works fine. I do have a running X server, which I've tested with other native apps, so I know at least that part is functional. Thanks, Matt -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-when-running-winforms-app-on-arm-processor-tp3064820p3064820.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ 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] Trying to find source for DispatcherObject.cs
Thank you. I am new to the mono source tree and still trying to find my way around things. I appreciate it. On Thu, Jan 13, 2011 at 1:48 AM, Robert Jordan robe...@gmx.net wrote: On 12.01.2011 23:35, Brad Cunningham wrote: I am seeing a strange error in the DispatcherObject in 2.8.1 and I am having trouble finding the source code to confirm the error. For those interested my issue is this: I can confirm that my object is being constructed on the same thread that the VerifyAccess call is occurring. In both places, ctor and VerifyAccess call, I can confirm that the Dispatcher is null. I would assume when the Dispatcher is null that the verify access should do nothing and be fine, however I am getting an exception that the call to verify access is occurring on a different thread than the ctor occurred on. If someone could point me to where the source is for this class I would appreciate it. https://github.com/mono/mono/tree/master/mcs/class/WindowsBase/System.Windows.Threading Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Brad Cunningham Microsoft MVP: C# http://blog.bradcunningham.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xsp2 won't run when invoked as service
hi, Thanks for clue, but it did not help. I've done: chmod -R a+rwx myapp and the result is the same as in previous email. Tomasz Kubacki Dnia 2011-01-12, śro o godzinie 19:40 -0600, Eddy Zavaleta pisze: Hi, It seems to be an access right (permission) problem. You should verify what user own the service and if that user has access to your app's path. To make sure everyone can read your app's path try executing: $ chmod -R a+r /path/to/your/web/app On Wed, Jan 12, 2011 at 4:18 PM, Tomasz Kubacki tomasz.kuba...@gmail.com wrote: Hi, I've sheeva plug box (arm) with default mono 2.6.1 and facing strange issue. I can run my asp.net app from console without any problems, but when i try to run it as a service i've got below error on request. What can cause this ? cheers, Tomasz Kubacki - Error: System.UnauthorizedAccessException: Access to the path /root/Piecyk/[Unknown] is denied. at System.IO.FileStream.ReadData (IntPtr handle, System.Byte[] buf, Int32 offset, Int32 count) [0x0] in filename unknown:0 at System.IO.FileStream.ReadInternal (System.Byte[] dest, Int32 offset, Int32 count) [0x0] in filename unknown:0 at System.IO.FileStream.Read (System.Byte[] array, Int32 offset, Int32 count) [0x0] in filename unknown:0 at System.IO.StreamReader.ReadBuffer () [0x0] in filename unknown:0 at System.IO.StreamReader.ReadLine () [0x0] in filename unknown:0 at System.IO.UnexceptionalStreamReader.ReadLine () [0x0] in filename unknown:0 at System.IO.SynchronizedReader.ReadLine () [0x0] in filename unknown:0 at System.Console.ReadLine () [0x0] in filename unknown:0 at Mono.WebServer.XSP.Server.RealMain (System.String[] args, Boolean root, IApplicationHost ext_apphost, Boolean quiet) [0x0] in filename unknown:0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Eddy Zavaleta mictlanix.org ___ 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 StopRoutingHandler - stop handling routes instead of throwing
On Fri, 14 Jan 2011 15:43:08 +0100 Damir Simunic damir.simu...@wa-research.ch wrote: Hi all, Hey, noticed that adding routes using StopRoutingHandler() throws NotSupportedExceptions instead of simply ceasing further processing in the UrlRoutingModule. Attached is the patch I wrote to change that behavior on master branch, accompanied with a unit test. Committed to master, mono-2-10 and mono-2-8 - thanks for the contribution :) marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] crash on first runtime_invoke (using MSVC build)
Recently, I had some problem with the VS2010 build of mono. Runtime check complains ESP is wrong after first time runtime_invoke is called. I traced it back to this single-line commit. (Reverting this single line avoids the problem on any version up to master) 08f0bcaad89540260323f24811cbf896cfe471ed Mark runtime invoke wrappers as pinvoke, since they are called from native code. diff --git a/mono/metadata/marshal.c b/mono/metadata/marshal.c index 476d129..c586555 100644 --- a/mono/metadata/marshal.c +++ b/mono/metadata/marshal.c @@ -4571,6 +4571,7 @@ mono_marshal_get_runtime_invoke (MonoMethod *method, gboolean virtual) csig-params [1] = mono_defaults.int_class-byval_arg; csig-params [2] = mono_defaults.int_class-byval_arg; csig-params [3] = mono_defaults.int_class-byval_arg; + csig-pinvoke = 1; name = mono_signature_to_name (callsig, virtual ? runtime_invoke_virtual : runtime_invoke); mb = mono_mb_new (target_klass, name, MONO_WRAPPER_RUNTIME_INVOKE); ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't compile mono 2.8 for ARM Linux 2.6.24
I have fixed the pthread lib but now there's a new problem when compiling. Now when I try to compile this happens. CC libmonoruntime_static_la-runtime.lo CC libmonoruntime_static_la-reflection.lo CC libmonoruntime_static_la-security.lo CC libmonoruntime_static_la-security-core-clr.lo CC libmonoruntime_static_la-security-manager.lo CC libmonoruntime_static_la-string-icalls.lo CC libmonoruntime_static_la-sysmath.lo CC libmonoruntime_static_la-threads.lo CC libmonoruntime_static_la-threadpool.lo CC libmonoruntime_static_la-verify.lo LD libmonoruntime-static.la CC libmonoruntimesgen_la-console-unix.lo CC libmonoruntimesgen_la-appdomain.lo CC libmonoruntimesgen_la-assembly.lo CC libmonoruntimesgen_la-attach.lo CC libmonoruntimesgen_la-boehm-gc.lo CC libmonoruntimesgen_la-class.lo CC libmonoruntimesgen_la-cominterop.lo CC libmonoruntimesgen_la-debug-helpers.lo CC libmonoruntimesgen_la-debug-mono-symfile.lo CC libmonoruntimesgen_la-decimal.lo CC libmonoruntimesgen_la-domain.lo CC libmonoruntimesgen_la-environment.lo CC libmonoruntimesgen_la-exception.lo CC libmonoruntimesgen_la-file-io.lo CC libmonoruntimesgen_la-filewatcher.lo CC libmonoruntimesgen_la-gc.lo CC libmonoruntimesgen_la-icall.lo CC libmonoruntimesgen_la-image.lo CC libmonoruntimesgen_la-loader.lo CC libmonoruntimesgen_la-locales.lo CC libmonoruntimesgen_la-lock-tracer.lo CC libmonoruntimesgen_la-marshal.lo CC libmonoruntimesgen_la-mempool.lo CC libmonoruntimesgen_la-metadata.lo CC libmonoruntimesgen_la-metadata-verify.lo CC libmonoruntimesgen_la-method-builder.lo CC libmonoruntimesgen_la-mono-basic-block.lo CC libmonoruntimesgen_la-mono-config.lo CC libmonoruntimesgen_la-mono-debug.lo CC libmonoruntimesgen_la-mono-debug-debugger.lo CC libmonoruntimesgen_la-mono-endian.lo CC libmonoruntimesgen_la-mono-hash.lo CC libmonoruntimesgen_la-mono-mlist.lo CC libmonoruntimesgen_la-mono-perfcounters.lo CC libmonoruntimesgen_la-mono-wsq.lo CC libmonoruntimesgen_la-monitor.lo monitor.c: In function 'mono_monitor_cleanup': monitor.c:128: warning: unused variable 'next' monitor.c:128: warning: unused variable 'marray' CC libmonoruntimesgen_la-null-gc.lo CC libmonoruntimesgen_la-object.lo CC libmonoruntimesgen_la-socket-io.lo CC libmonoruntimesgen_la-process.lo CC libmonoruntimesgen_la-profiler.lo CC libmonoruntimesgen_la-rand.lo CC libmonoruntimesgen_la-runtime.lo CC libmonoruntimesgen_la-reflection.lo CC libmonoruntimesgen_la-security.lo CC libmonoruntimesgen_la-security-core-clr.lo CC libmonoruntimesgen_la-security-manager.lo CC libmonoruntimesgen_la-sgen-os-posix.lo CC libmonoruntimesgen_la-sgen-os-mach.lo CC libmonoruntimesgen_la-sgen-gc.lo In file included from sgen-gc.c:784: sgen-los.c: In function 'los_scan_card_table': sgen-los.c:482: warning: initialization from incompatible pointer type sgen-los.c:501: warning: comparison of distinct pointer types lacks a cast sgen-gc.c: At top level: sgen-cardtable.c:230: warning: 'collect_faulted_cards' defined but not used CC libmonoruntimesgen_la-sgen-internal.lo CC libmonoruntimesgen_la-sgen-marksweep.lo sgen-marksweep.c: In function 'mark_pinned_objects_in_block': sgen-marksweep.c:925: warning: unused variable 'count' CC libmonoruntimesgen_la-sgen-marksweep-fixed.lo In file included from sgen-marksweep-fixed.c:3: sgen-marksweep.c: In function 'major_copy_or_mark_object': sgen-marksweep.c:861: warning: unused variable 'objsize' In file included from sgen-marksweep-fixed.c:3: sgen-marksweep.c: In function 'mark_pinned_objects_in_block': sgen-marksweep.c:925: warning: unused variable 'count' CC libmonoruntimesgen_la-sgen-marksweep-par.lo In file included from sgen-marksweep-par.c:3: sgen-marksweep.c: In function 'mark_pinned_objects_in_block': sgen-marksweep.c:925: warning: unused variable 'count' CC libmonoruntimesgen_la-sgen-marksweep-fixed-par.lo In file included from sgen-marksweep-fixed-par.c:4: sgen-marksweep.c: In function 'mark_pinned_objects_in_block': sgen-marksweep.c:925: warning: unused variable 'count' CC libmonoruntimesgen_la-sgen-major-copying.lo CC libmonoruntimesgen_la-string-icalls.lo CC libmonoruntimesgen_la-sysmath.lo CC libmonoruntimesgen_la-threads.lo CC libmonoruntimesgen_la-threadpool.lo CC libmonoruntimesgen_la-verify.lo LD libmonoruntimesgen.la CC libmonoruntimesgen_static_la-console-unix.lo CC libmonoruntimesgen_static_la-appdomain.lo CC libmonoruntimesgen_static_la-assembly.lo CC libmonoruntimesgen_static_la-attach.lo CC libmonoruntimesgen_static_la-boehm-gc.lo CC libmonoruntimesgen_static_la-class.lo CC libmonoruntimesgen_static_la-cominterop.lo CC
Re: [Mono-dev] Can't compile mono 2.8 for ARM Linux 2.6.24
mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or ARM_FPU_FPA or ARM_FPU_VFP must be defined. You need to pass -DARM_FPU_NONE in your CFLAGS. (Or one of the other choices if you have a hardware FPU) -Matt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem when running winforms app on arm processor
Geoff, I think this is what you asked for. Let me know if something looks funny - I'm new to gdb. Breakpoint 1, mono_arch_patch_callsite ( method_start=0x4153c048 \r\300\240, incomplete sequence \341, code_ptr=0x4153c0cc , addr=0x419759f8 \r\300\240\341`Y-\351H\320M\342\r\260\240, incomplete sequence \341) at tramp-arm.c:48 48 g_assert_not_reached (); (gdb) x/6i code-16 0x4153c088: addr0, r0, #3670016 ; 0x38 0x4153c08c: ldr r0, [r0] 0x4153c090: cmp r0, #0 0x4153c094: bne0x4153c0d8 0x4153c098: mov r0, #17 0x4153c09c: ldr r12, [pc, #0]; 0x4153c0a4 (gdb) Thanks, Matt From: Geoff Norton [mailto:gnorton.nov...@gmail.com] On Behalf Of Geoff Norton Sent: Friday, January 14, 2011 10:03 AM To: Matt Johnson Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Problem when running winforms app on arm processor Matt, We cannot replicate this problem, so you'll need to help narrow down the field. Can you get the gdb output of x/6i code-16 when gdb is at tramp-arm.c line 48? Thanks -g On 2011-01-14, at 11:28 AM, Matt Johnson wrote: PLEA FOR URGENT HELP Almost 7 weeks and not a single response on this except to confirm that another is also having the problem. Is there no one that can shed light on what is going on here? I cannot run any winforms apps on an arm processor without hitting the assertion in tramp-arm.c. I am willing to help in any way I can, but I'm not an assembly language programmer, nor am I familiar with reasons behind the patching that is going on in the arm trampoline, so I really need some assistance. Thank You. Matt From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Matt Johnson Sent: Monday, January 03, 2011 10:24 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Problem when running winforms app on arm processor No, I have no resolution yet. I have simplified my winforms test application such that it is a single form with a single text hello world label and no code logic whatsoever. It crashes in the exact same manner. One point I am unclear on is that I read in some old posts that the thumb instruction set is not supported. I am not compiling with thumb enabled, but I am using a toolchain that targets armv4t instead of straight armv4. I actually found it very difficult to even find an non-t toolchain out there - I'd have to compile one from scratch if this is the problem. I don't see how it could be though. Especially since it is only winforms apps that are failing. Can someone with some expertise with the arm trampoline please chime in here? It is fairly urgent. Thanks, Matt From: Jae Kim [mailto:jkim0...@gmail.com] Sent: Friday, December 17, 2010 10:52 AM To: mj1856 Subject: Re: [Mono-dev] Problem when running winforms app on arm processor Hi Matt, Did you ever resolve this? I'm experiencing the same problem. Thanks, Jae On Mon, Nov 29, 2010 at 7:44 PM, mj1856 mj1...@hotmail.com wrote: I have cross compiled mono 2.8 with libgdiplus for the s3c2410 processor I am running. It is an arm920t (armv4t architecture). I use scratchbox with a recent codesourcery toolchain. I have two test applications that I wrote in visual studio targeting .net 2.0. The first is a console app with a basic Hello world. It works perfectly. The second is a winforms app with a single form that has a simple label that gets updated with a timer control to show the current date and time. (basically a digital clock). Running it, I get the following error: * Assertion: should not be reached at tramp-arm.c:48 Checking /mono/mini/tramp-arm.c, the function in question is mono_arch_patch_callsite, which has two blocks of code, where one of them is supposed to run. I'm not sure exactly what it's checking here, but neither block gets executed, so it hits the assertion. Can anyone shed some light on what might be the problem? One note that may or may not be of interest, but because the codesourcery toolchain is multilib, I have to specify -march=armv4t on the CFLAGS passed to configure mono. This appears to be working, as my console app works fine. I do have a running X server, which I've tested with other native apps, so I know at least that part is functional. Thanks, Matt -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-when-running-winforms-app-on-arm-p rocessor-tp3064820p3064820.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com
Re: [Mono-dev] crash on first runtime_invoke (using MSVC build)
It crashes with all apps during mono_jit_init[_version] (which use mono_runtime_invoke internally) mono-2.0.dll!mono_jit_runtime_invoke(_MonoMethod * method, void * obj, void * * params, MonoObject * * exc) Line 5700 C mono-2.0.dll!mono_runtime_invoke(_MonoMethod * method, void * obj, void * * params, MonoObject * * exc) Line 2727 + 0x18 bytes C mono-2.0.dll!create_exception_two_strings(_MonoClass * klass, _MonoString * a1, _MonoString * a2) Line 134 + 0x13 bytes C mono-2.0.dll!mono_exception_from_name_two_strings(_MonoImage * image, const char * name_space, const char * name, _MonoString * a1, _MonoString * a2) Line 157 + 0x11 bytes C mono-2.0.dll!create_domain_objects(_MonoDomain * domain) Line 177 + 0x1c bytes C mono-2.0.dll!mono_runtime_init(_MonoDomain * domain, void (int, void *, void *)* start_cb, void (int, void *)* attach_cb) Line 261 + 0x9 bytes C mono-2.0.dll!mini_init(const char * filename, const char * runtime_version) Line 6514 + 0x13 bytes C mono-2.0.dll!mono_jit_init_version(const char * domain_name, const char * runtime_version) Line 2043 + 0xd bytes C On Sat, Jan 15, 2011 at 9:20 AM, Zoltan Varga var...@gmail.com wrote: Hi, Do you have a testcase, or does this happen with all apps ? Zoltan On Fri, Jan 14, 2011 at 10:58 PM, Virgile Bello virgile.be...@gmail.comwrote: Recently, I had some problem with the VS2010 build of mono. Runtime check complains ESP is wrong after first time runtime_invoke is called. I traced it back to this single-line commit. (Reverting this single line avoids the problem on any version up to master) 08f0bcaad89540260323f24811cbf896cfe471ed Mark runtime invoke wrappers as pinvoke, since they are called from native code. diff --git a/mono/metadata/marshal.c b/mono/metadata/marshal.c index 476d129..c586555 100644 --- a/mono/metadata/marshal.c +++ b/mono/metadata/marshal.c @@ -4571,6 +4571,7 @@ mono_marshal_get_runtime_invoke (MonoMethod *method, gboolean virtual) csig-params [1] = mono_defaults.int_class-byval_arg; csig-params [2] = mono_defaults.int_class-byval_arg; csig-params [3] = mono_defaults.int_class-byval_arg; + csig-pinvoke = 1; name = mono_signature_to_name (callsig, virtual ? runtime_invoke_virtual : runtime_invoke); mb = mono_mb_new (target_klass, name, MONO_WRAPPER_RUNTIME_INVOKE); ___ 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
