[Mono-devel-list] Assertion failed when compiling Cuyahoga on amd64
Hello, As in subject, compilation of Cuyahoga (from svn) using NAnt nightly build (2005-03-08) and mono 1.1.4 (yesterday night's checkout from svn) on an Opteron 140 machine running Debian/sid triggers the following message: ** ERROR **: file tramp-amd64.c: line 98 (amd64_magic_trampoline): assertion failed: (*vtable_slot) aborting... lenghty output of gdb bt and bt full is attached. Please let me know if I can do anything to help further diagnose the problem, regards, marek session.gdb.bz2 Description: Binary data signature.asc Description: Digital signature
[Mono-devel-list] [PATCH] CAS support for stack walk on p/invoke methods
Hello,
This patch generates code to do a stack walk (Demand for
SecurityPermissionFlag.UnmanagedCode) before calling into p/invoke
method. This code only gets called if the security manager is active
(mono --security).
The [SuppressUnmanagedCodeSecurity] attribute can be used on the
p/invoke method declaration or on it's class to suppress the stack walk
(e.g. it can provide a nice performance boost if the assembly has a
[assembly: SecurityPermission (RequestMinimum, UnmanagedCode=true)]).
Tests have already been committed under
/mono/mono/tests/cas/demand/
Thanks for reviewing.
--
Sebastien Pouliot [EMAIL PROTECTED]
blog: http://pages.infinit.net/ctech/poupou.html
Index: mini.c
===
--- mini.c (revision 41689)
+++ mini.c (working copy)
@@ -3153,7 +3153,8 @@
int num_calls = 0, inline_costs = 0;
int breakpoint_id = 0;
guint real_offset, num_args;
- MonoBoolean security;
+ MonoBoolean security, pinvoke;
+ MonoSecurityManager* secman = NULL;
MonoDeclSecurityActions actions;
image = method-klass-image;
@@ -3282,7 +3283,10 @@
}
}
- security = mono_use_security_manager mono_method_has_declsec (method);
+ if (mono_use_security_manager)
+ secman = mono_security_manager_get_methods ();
+
+ security = (secman mono_method_has_declsec (method));
/* at this point having security doesn't mean we have any code to generate */
if (security (cfg-method == method)) {
/* Only Demand, NonCasDemand and DemandChoice requires code generation.
@@ -3290,8 +3294,32 @@
* have nothing to generate */
security = mono_declsec_get_demands (method, actions);
}
+
+ /* we must Demand SecurityPermission.Unmanaged before P/Invoking */
+ pinvoke = (secman (method-wrapper_type == MONO_WRAPPER_MANAGED_TO_NATIVE));
+ if (pinvoke) {
+ MonoMethod *wrapped = mono_marshal_method_from_wrapper (method);
+ if (wrapped (wrapped-flags METHOD_ATTRIBUTE_PINVOKE_IMPL)) {
+ MonoCustomAttrInfo* custom = mono_custom_attrs_from_method (wrapped);
+
+ /* unless the method or it's class has the [SuppressUnmanagedCodeSecurity] attribute */
+ if (custom mono_custom_attrs_has_attr (custom, secman-sucs)) {
+pinvoke = FALSE;
+ }
+
+ if (pinvoke) {
+custom = mono_custom_attrs_from_class (wrapped-klass);
+if (custom mono_custom_attrs_has_attr (custom, secman-sucs)) {
+ pinvoke = FALSE;
+}
+ }
+ } else {
+ /* not a P/Invoke after all */
+ pinvoke = FALSE;
+ }
+ }
- if ((header-init_locals || (cfg-method == method (cfg-opt MONO_OPT_SHARED))) || mono_compile_aot || security) {
+ if ((header-init_locals || (cfg-method == method (cfg-opt MONO_OPT_SHARED))) || mono_compile_aot || security || pinvoke) {
/* we use a separate basic block for the initialization code */
cfg-bb_init = init_localsbb = NEW_BBLOCK (cfg);
init_localsbb-real_offset = real_offset;
@@ -3308,7 +3336,6 @@
/* at this point we know, if security is TRUE, that some code needs to be generated */
if (security (cfg-method == method)) {
MonoInst *args [2];
- MonoSecurityManager* secman = mono_security_manager_get_methods ();
mono_jit_stats.cas_demand_generation++;
@@ -3336,6 +3363,11 @@
}
}
+ /* we must Demand SecurityPermission.Unmanaged before p/invoking */
+ if (pinvoke) {
+ mono_emit_method_call_spilled (cfg, init_localsbb, secman-demandunmanaged, mono_method_signature (secman-demandunmanaged), NULL, ip, NULL);
+ }
+
if (get_basic_blocks (cfg, bbhash, header, real_offset, ip, end, err_pos)) {
ip = err_pos;
goto unverified;
Index: security-manager.c
===
--- security-manager.c (revision 41701)
+++ security-manager.c (working copy)
@@ -42,6 +42,10 @@
InternalDemandChoice, 2);
g_assert (secman.demandchoice);
+ secman.demandunmanaged = mono_class_get_method_from_name (secman.securitymanager,
+ DemandUnmanaged, 0);
+ g_assert (secman.demandunmanaged);
+
secman.inheritancedemand = mono_class_get_method_from_name (secman.securitymanager,
InheritanceDemand, 2);
g_assert (secman.inheritancedemand);
@@ -70,6 +74,10 @@
AllowPartiallyTrustedCallersAttribute);
g_assert (secman.aptc);
+ secman.sucs = mono_class_from_name (mono_defaults.corlib, System.Security,
+ SuppressUnmanagedCodeSecurityAttribute);
+ g_assert (secman.sucs);
+
return secman;
}
Index: security-manager.h
===
--- security-manager.h (revision 41701)
+++ security-manager.h (working copy)
@@ -39,6 +39,7 @@
MonoClass *securitymanager; /* System.Security.SecurityManager */
MonoMethod *demand; /* SecurityManager.InternalDemand */
MonoMethod *demandchoice; /* SecurityManager.InternalDemandChoice */
+ MonoMethod *demandunmanaged; /* SecurityManager.DemandUnmanaged */
MonoMethod *inheritancedemand; /* SecurityManager.InheritanceDemand */
MonoMethod *inheritsecurityexception; /*
Re: [Mono-devel-list] patch for TypeBuilder.CreateType() and mcs
Ben Maurer wrote: On Fri, 2005-03-11 at 04:41 +0900, Atsushi Eno wrote: Hi, I noticed that TypeBuilder never throws InvalidOperationException when CreateType() is invoked twice. It is because of this change: 2004-12-06 Ben Maurer [EMAIL PROTECTED] * TypeBuilder.cs (CreateType): Creating a type twice does not throw in msft. I have no idea why I found this change. Are there test cases in mcs that break with this patch (and without the mcs one)? Mhm, on fixing those mcs sources I was on the wrong path; it was my changes to doc.cs (reverted) caused crash (and fix) with the patch on my xml test stuff. So, for now there seems no need to change mcs stuff. I retried tests and it worked fine without mcs changes. Interesting. I'd like to find out why I added this patch. I wouldn't normally be hacking stuff there, so I must have been fixing *something*. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] Changes required to compile Mono HEAD with Visual Studio.NET 2005
Hello everyone,
Here's an updated patch to make mono HEAD compilable with VS.NET 2005
(and probably earlier versions too). Please note that most of the
changes are from the previous work of J Lothian. Thanks again!
There is no project/solution files attached as I still have to clean
them from system (mine) specific paths... and reorganize it to avoid
some warnings. With a little luck it will be possible to add them in SVN
alter without requiring much custom editing.
The changes do not seems to affect compilation/results of Mono under
cygwin or Linux. However I do not know if this affects compilation under
mingw. Anyone using mingw to compile Mono ?
*** Main issues ***
[1] __builtin_frame_address(1) is a lot more complex to implement
than __builtin_frame_address(0)
This means that some samples (like the embedded samples) don't
work but (hapilly ;-) I'm able to do the security stack walk
(because they do not requires (1)).
My last attempt to fix that (using naked functions) failed :-(.
I will give it another try this weekend.
[2] MS C (Microsoft C compiler) doesn't like empty enums. We got one
like that in mini-x86.c.
Here is a description of the changes...
/mono/io-layer/
* io-layer.h
Include winsock2.h before windows.h. Added missing includes
required by MSC.
/mono/mono/metadata/
* appdomain.c
Type casting to LPTHREAD_START_ROUTINE in CreateThread
* appdomain.h
Changed inline to MONO_INLINE as MSC doesn't like this case of
inlining
* assembly.c
add include for msc.h (for MONO_ASSEMBLIES)
* domain.c
Removed inline from functions (they are already inline in
appdomain.h) because they cause link errors with MSC
* threads.c
Add required typecast.
MSC similar to MINGW32
* sysmath.h
include msc.h when compiled with MSC
* rawbuffer.c
include winsock2.h before windows.h
* rand.c
include windows.h before WinCrypt.h
removed warning (missing typecast)
/mono/mono/mini/
aot.c
* include winsock2.h before windows.h
mini.h
* include mono/metadata/msc.h (new file) when compiled with MSC
mini-exceptions.c
* replace usage of __builtin_frame_address and __builtin_return_address
(GCC) with MSC equivalent
!!! See issue [1]
mini-x86.c
* MSC doesn't like empty enum vector;
!!! not sure if this is ok !!! see [2]
* changed to inline assembly to MSC format
mini-x86.h
* MSC doesn't like empty struct
/mono/os/
gc_wrapper.h
Include winsock2.h before including anything else (windows.h
in particular) from gc.
--
Sebastien Pouliot [EMAIL PROTECTED]
blog: http://pages.infinit.net/ctech/poupou.html
Index: mono/metadata/domain.c
===
--- mono/metadata/domain.c (revision 41706)
+++ mono/metadata/domain.c (working copy)
@@ -682,7 +682,7 @@
*
* Returns: the current domain.
*/
-inline MonoDomain *
+MonoDomain *
mono_domain_get ()
{
return GET_APPDOMAIN ();
@@ -694,7 +694,7 @@
*
* Sets the current domain to @domain.
*/
-inline void
+void
mono_domain_set_internal (MonoDomain *domain)
{
SET_APPDOMAIN (domain);
Index: mono/metadata/appdomain.c
===
--- mono/metadata/appdomain.c (revision 41706)
+++ mono/metadata/appdomain.c (working copy)
@@ -1373,7 +1373,7 @@
#if 0
thread_handle = CreateThread (NULL, 0, unload_thread_main, thread_data, 0, tid);
#else
- thread_handle = CreateThread (NULL, 0, unload_thread_main, thread_data, CREATE_SUSPENDED, tid);
+ thread_handle = CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)unload_thread_main, thread_data, CREATE_SUSPENDED, tid);
ResumeThread (thread_handle);
#endif
Index: mono/metadata/appdomain.h
===
--- mono/metadata/appdomain.h (revision 41706)
+++ mono/metadata/appdomain.h (working copy)
@@ -16,6 +16,12 @@
#include mono/metadata/reflection.h
#include mono/metadata/mempool.h
+#ifdef _MSC_VER
+#define MONO_INLINE
+#else
+#define MONO_INLINE inline
+#endif
+
typedef void (*MonoThreadStartCB) (guint32 tid, gpointer stack_start,
gpointer func);
typedef void (*MonoThreadAttachCB) (guint32 tid, gpointer stack_start);
@@ -59,19 +65,19 @@
MonoDomain *
mono_domain_create (void);
-inline MonoDomain *
+MONO_INLINE MonoDomain *
mono_domain_get(void);
-inline MonoDomain *
+MONO_INLINE MonoDomain *
mono_domain_get_by_id (gint32 domainid);
gint32
mono_domain_get_id (MonoDomain *domain);
-inline gboolean
+MONO_INLINE gboolean
mono_domain_set(MonoDomain *domain, gboolean force);
-inline void
+MONO_INLINE void
mono_domain_set_internal (MonoDomain *domain);
gboolean
@@ -101,10 +107,10 @@
void
mono_context_init (MonoDomain *domain);
-inline void
+MONO_INLINE void
Re: [Mono-devel-list] Leak in System.Timers.Timer?
Our current gc, is conservative and not very aggressive at freeing
resources, you may be creating your objects way too fast...
Can't you reuse the timer? Seems to be a wiser solution reuing objects
as even a good gc may spend precious processing time if it has to
collect zillions of short-lived objects...
Just my 2 cents, :)
On Thu, 10 Mar 2005 15:07:55 -0500, Brian Kroeker [EMAIL PROTECTED] wrote:
I haven't installed mono on windows but using the MS Framework I don't see
this behavior on windows. Also I don't believe this could be a
lapsed-listener, since I'm subscribing to an event in the instance of timer
- when all references to timer are gone shouldn't the garbage collector get
rid of the object including its event and list of delegates? I didn't think
the delegates stuck around after the event went away.
Brian
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, March 10, 2005 12:03 PM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-devel-list] Leak in System.Timers.Timer?
Oh, wait I see you are passing the same one by ref and setting it to null.
Do you get different behaviour under windows?
Joe Audette [EMAIL PROTECTED] wrote:
Looks to me like your creating timers in an infinite loop wich would of
course continue to consume resources
while(true)
{
InitTimeout(ref timeout);
System.Threading.Thread.Sleep(10);
}
true will always be true so you are spinning off a lot of timers right? Or
am I missing something?
Regards,
Joe
Brian Kroeker [EMAIL PROTECTED] wrote:
I'm seeing what looks like a memory leak somewhere in System.Timers.Timer.
I'm using mono 1.1.4 on a linux system. The code I used to reproduce the
problem is:
--
using System;
namespace TimerTest
{
public class TimerTest
{
static void Main(string[] args)
{
TimerTest test = new TimerTest();
test.Run();
}
public TimerTest()
{
}
public void Run()
{
System.Timers.Timer timeout = null;
while(true)
{
InitTimeout(ref timeout);
System.Threading.Thread.Sleep(10);
}
}
private void InitTimeout(ref System.Timers.Timer timer)
{
if(timer != null)
{
timer.Stop();
timer = null;
}
timer = new System.Timers.Timer();
timer.AutoReset = false;
timer.Elapsed += new
System.Timers.ElapsedEventHandler(OnTimeout);
timer.Interval = 3;
timer.Start();
}
private void OnTimeout(object source, System.Timers.ElapsedEventArgs
e)
{
}
}
}
--
Does anyone else see this problem? Am I missing something here? I see the
memory usage on my system increase fairly quickly.
Thanks,
Brian
[EMAIL PROTECTED]
http://www.joeaudette.com
http://www.mojoportal.com
[EMAIL PROTECTED]
http://www.joeaudette.com
http://www.mojoportal.com
--
Rafael Monoman Teixeira
---
I'm trying to become a Rosh Gadol before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for SqlConnection
Hi Suresh,
A programmer may forget to close a connection before it is collected.
Surely in the server-side there are resouces that should be freed.
That is why SQLConnection DOES have unmanaged resources to free. If
our implementation isn't doing so in the finalizer/dispose it is in
error, period.
HIH,
On Fri, 11 Mar 2005 12:56:05 +0530, Sureshkumar T
[EMAIL PROTECTED] wrote:
From: Gonzalo Paniagua Javier [EMAIL PROTECTED]
To: Mono Development mono-devel-list@lists.ximian.com
Subject: [Mono-devel-list] Patch for SqlConnection
Date: Fri, 11 Mar 2005 00:50:59 -0500
Hi.
Attached there's a small patch that adds a finalizer to SqlConnection
and moves the 'disposed = true' into the finally in Dispose(bool).
SqlConnection does not have any unmanaged resources. Hence, IMHO, it is
not necessary to have finalizer method. We can avoid an overhead to GC.
I donot see the reason to mark disposed to true in case any exception
occurs while closing the connection.
-suresh.
Any objections?
-Gonzalo
--=-yYoFVNPF2KxporljqjIH
Content-Disposition: attachment; filename=patchety.patch
Content-Type: text/x-patch; name=patchety.patch; charset=UTF-8
Content-Transfer-Encoding: 7bit
Index: SqlConnection.cs
===
--- SqlConnection.cs (revision 41656)
+++ SqlConnection.cs (working copy)
@@ -411,11 +411,10 @@
dataSource = ; //
default dataSource
ConnectionString = null;
}
+} finally {
disposed = true;
-} finally {
base.Dispose (disposing);
}
-
}
}
@@ -455,6 +454,11 @@
GC.SuppressFinalize (this);
}
+ ~SqlConnection ()
+ {
+ Dispose (false);
+ }
+
public
#if NET_2_0
override
--=-yYoFVNPF2KxporljqjIH--
___
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
--
Rafael Monoman Teixeira
---
I'm trying to become a Rosh Gadol before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for SqlConnection
On Fri, 2005-03-11 at 12:56 +0530, Sureshkumar T wrote: Attached there's a small patch that adds a finalizer to SqlConnection and moves the 'disposed = true' into the finally in Dispose(bool). SqlConnection does not have any unmanaged resources. Hence, IMHO, it is not necessary to have finalizer method. We can avoid an overhead to GC. Then I wonder what a connection to a database is... The problem is that if the user forgets about calling Close, the connection is never released from the conneciton pool. I donot see the reason to mark disposed to true in case any exception occurs while closing the connection. It's just that 'disposed' will never be true if there's a exception, but if you don't care about that... -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] New Mono community
Hi! Rogerio, excuse for my intromission :D Another portuguese site: http://www.br-mono.org (running on mono). I utilize this mail to thank to Steve Deobald from www.cityhost.ca for the help to host and make possible to run this site on Mono I have create this site to show the capacity of Mono run ASP.NET applications, share my little knowlede on Mono, and open space to another Brazilian Mono Developers share your skills. The final target don't is create a mega-ultra portal, but just give my 0,2 cents to Mono evangelization in Brazil. Thanks :) Cassio Rogério Eskelsen (Sorry, my english is very, very bad!! Because that, the site is br-mono.org and not en-mono.org :-D ) On Fri, 11 Mar 2005 11:43:53 -0300, Rogerio Pereira [EMAIL PROTECTED] wrote: Hi Mono folks, I'm inviting all Mono developers that speak Portuguese to join in our new Mono community (www.simios.org) to share your skills and help the newbies in this platform. Regards, -- Rogério Pereira Araújo Programador / Pesquisador Departamento de desenvolvimento - Divisão de pesquisa tecnológica CS Computadores e Sistemas Ltda. www.cisnet.com.br ___ 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
