Hi,
I spent a few hours yesterday trying to reproduce your bug without success.
I have to say that from your valgrind result, the issue is closely related
to how
your perforce library interact with unmanaged code - it happens when you
pass a delegate to a pinvoke and somehow memory is leaked.
Do
Hey guys,
Reading the ppc code for exception handling seens like we could get rid of
the
CUSTOM_EXCEPTION_HANDLING define and a big chunk of ppc specific code.
I can't spot any platform specific code in in
exceptions-ppc.c::arch_handle_exception
comparing to
Hi Casey,
We did a lot of work fixing many kinds of memory leaks under the runtime and
JIT.
There are a few know issues, but none that would show in valgrind like this.
And none
that would leak that much.
I'll take a look at this issue in the comming days to see if I can narrow it
down.
In the
the GList memory originally allocated by the JIT.
Rodrigo Kumpera wrote:
Hi Casey,
We did a lot of work fixing many kinds of memory leaks under the runtime
and JIT.
There are a few know issues, but none that would show in valgrind like
this. And none
that would leak that much.
I'll take a look
Hey guys,
Given the typo I found in new the linear-ir code, I decided to take a look
at all defines we have in the JIT so we can sanitize usage and document
then.
It turns out that we have more typos on our tree and a huge amount of
defines in the wild. It's hard for me to grasp
the meaning of
, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Your mscorlib or monorunapp.exe seens to be corrupted.
On Fri, Aug 8, 2008 at 8:35 PM, Jolting [EMAIL PROTECTED] wrote:
I cross compiled mono and when I ran it I got the following error.
** (../monorunapp.exe:582): CRITICAL **: mono_metadata_string_heap
Hey guys,
I just got myself into a roadblock today while fixing overflow arithmetic
under ARM. The issue is that the emitted IR
cannot be properly translated to native code.
The ARM ISA has the oddity that carry/borrow works in the opposite way. Add
with carry do a +1 if the carry bit is set,
Hi Zoltan,
method-to-ir.c has a misspelled define.
MONO_ARCH_NO_EMULATE_LONG_SHIFT_OPTS instead of
MONO_ARCH_NO_EMULATE_LONG_SHIFT_OPS as in mini.c
I guess changing this will pop up some errors in mono_decompose_long_opts.
Cheers,
Rodrigo
___
On Wed, Jul 30, 2008 at 4:08 AM, Massimiliano Mantione [EMAIL PROTECTED]wrote:
I know finding a spare bit in MonoMethod is impossible :-)
On Tue, 2008-07-29 at 20:48 -0300, Rodrigo Kumpera wrote:
Other option is to kill the inline_info bit in MonoMethod and
use the space
Hi Zoltan,
It's only doable to encode some very simple icalls with IL. I have the
feeling that
we get an order of magnitude code increase for going from C/C# to emitting
IL.
OTOH, for things like UnsafeAddrOfPinnedArrayElement, the code is so
straight
forward that gcc will hardly do much better
Varadhan,
Depending on exception on regular paths might lead to disastrous
performance.
Is this just a corner case for compatibility or this kind of situation might
happen often?
We might need to document this shortcoming of our stack.
Thanks,
Rodrigo
On Wed, Jul 30, 2008 at 10:56 AM,
Hi Kornél,
From your email the advantage of the patch is that by replacing some icalls
with managed code we would get rid of some managed-native transitions.
But there are some side effects:
-It makes the new full AOT mode a bit more complicated as these would be
another
kind of wrappers that
This change is 100% harmless to not get in, go ahead and commit it.
Thanks for the contribution
Rodrigo
2008/7/29 Bill Holmes [EMAIL PROTECTED]
Hello All,
Does anyone mind if I backport r108759 to the 2-0 branch? The diff
for that change is attached.
-bill
One thing, use a separate Changelog entry please.
On Tue, Jul 29, 2008 at 5:33 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
This change is 100% harmless to not get in, go ahead and commit it.
Thanks for the contribution
Rodrigo
2008/7/29 Bill Holmes [EMAIL PROTECTED]
Hello All,
Does
On Tue, Jul 29, 2008 at 7:35 PM, Kornél Pál [EMAIL PROTECTED] wrote:
-For simple methods such as OffsetToStringData the method call overhead
might be a killer. We
should make sure that these new wrappers get a change to be inlined.
Currently it doesn't get inlined because the JIT has some
Hi Bill,
You forgot to attach the patch.
Anyway, since Zoltan is merging linear-il tomorrow it might be better for
you to rebase your patch first.
Rodrigo
On Mon, Jul 21, 2008 at 8:20 PM, Bill Holmes [EMAIL PROTECTED] wrote:
Hello All,
The attached patch focuses on fixes needed for calls
On Sun, Jul 20, 2008 at 11:59 AM, Massimiliano Mantione [EMAIL PROTECTED]
wrote:
Hello!
Rodrigo and others were asking to extend the stat profiler to recognize
also trampolines and thunks (right now they show up as unknown).
I have looked at the code, and found that the different
How about disabling generic sharing for the 2.0 release and have a better
debugger experience for our users?
For me if gsharing breaks the debugger we can't say it's done. Enabling by
default something that breaks a
very important piece of our stack is not the way to go.
I would say that we go
On Tue, Jul 15, 2008 at 2:14 PM, Mark Probst [EMAIL PROTECTED] wrote:
On Tue, Jul 15, 2008 at 6:57 PM, Rodrigo Kumpera [EMAIL PROTECTED]
wrote:
How about disabling generic sharing for the 2.0 release and have a better
debugger experience for our users?
For me if gsharing breaks
Hi Massi,
The attached patch changes the new profiler to use the complete name of
types, this solves two issues I'm facing.
First, nested types don't carry the name of the outer type; and second,
generic types neither carry their instantiation or
are grouped together by the generic definition.
good suggestion ;)
Attached is a patch that only contains the Is* changes.
Happy Hacking
Andreas
*Von:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *Im Auftrag von *Rodrigo Kumpera
*Gesendet:* Samstag, 28. Juni 2008 00:37
*An:* Andreas Nahr
*Cc:* mono-devel
*Betreff:* Re: [Mono-dev
Hi David,
This is a very hard subject, as validating a memory model is an incredible
hard task.
Right now we provide loose semantics close to ecma backed by the
architecture
you're running. This means we do a very different thing in, say, X86 and
Itanium.
Having a consistent memory model is a
Andreas,
How about splitting your patches in two? One with the lesser risky
CheckParameter changes and other with the Is*** changes.
The CheckParameter changes look lovely, go ahead commit then.
I would like to do some testing on other changes, that are more comple and
unfortunately I won't have
Your patch have a huge ammount of useless whitespace changes, these make
reviews a lot hard.
Please provide some benchmarks so we can run it locally and see the
performance improvements.
I would say that moving the argumento checks to a funcion is a bad idea. We
should move the exception
raising
This patch looks fine to be commited.
2008/6/18 Kornél Pál [EMAIL PROTECTED]:
Hi,
This patch implements GetHINSTANCE:
Returns HINSTANCE (same as HMODULE) for modules loaded using LoadLibrary,
otherwise returns -1. As a result -1 is returned on non-Windows platforms.
If you like the
Hi Avinash,
I'm not exactly sure about what your issue is. Seens like you found a bug on
the culture of referenced assemblies. If that the case, mind filling a bug
report with a test case that shows it?
2008/6/18 [EMAIL PROTECTED]:
Hi,
*Platform: *Mono Built ON Solaris 7 SPARC 32.
Hi Martin,
The attached patch fixes two memory leaks related to how
mono-debug.c::find_method works.
The patch moves mono_debug_free_method_jit_info from mini/debug-mini.c to
metadata/mono-debug.c and
add it to the public API.
The first memleak happens from ves_icall_System_Exception_get_trace
Please fill a bug report and we will take a look.
On Wed, Jun 4, 2008 at 10:16 AM, CastleSoft [EMAIL PROTECTED]
wrote:
I've install the last 2 nightly snapshots (currently using 104788) for
OpenSuSe 10.3.
Basic asp.net 2.0 stuff via xsp2 and lighttpd working.
Got mysql/latest build etc
Hey Miguel,
It's not safe to call mono_global_codeman_reserve from an async signal
handler. Thanks for reviewing and catching this one.
Rodrigo
On Fri, May 23, 2008 at 12:57 PM, Miguel de Icaza [EMAIL PROTECTED] wrote:
Hello Rodrigo,
In mono_arch_get_call_interrupt_trampoline which is
Hey,
The attached patch implements managed code thread abort by installing a
trampoline on signal return.
This patch introduces two new arch specific functions, that I'll port to arm
and amd64 once the current patch
is committed:
void mono_arch_set_ip_in_context (void *sigctx, void *new_ip)
to either release these changes under the X11 license
or have done some copyright assignment paperwork.
Thanks,
Rodrigo
On Thu, May 8, 2008 at 8:21 PM, Luis F. Ortiz [EMAIL PROTECTED] wrote:
On May 8, 2008, at 9:29 AM, Rodrigo Kumpera wrote:
One important thing I forgot. If you break your
to clean this up in the original
check-in and makes naming convention inconsistent. I'll commit that as a
separate revision.
Note that tests having Msvcrt in their names are not woring on Mono yet.
Kornél
- Original Message - From: Rodrigo Kumpera [EMAIL PROTECTED]
To: Kornél Pál
Hi Kornél,
What is the reason of your changes in threads.c? I can't see it making any
diference and it's possibly racy as there is no membar around the new static
variable.
@@ -203,7 +221,7 @@
IMAGE_DOS_HEADER* DosHeader;
IMAGE_NT_HEADERS* NtHeaders;
DWORD* Address;
-
at 23:50 -0300, Rodrigo Kumpera wrote:
To have your patch integrated, some changes are needed. First, we want
to default to 32bits sized arrays on 64bits machines
Silly question, but why? We have Mono 2.0 coming up, so it should be
safe to change the public API/ABI to support 64-bit arrays
-like sockets, file i/o and so on.
Cheers,
Rodrigo
On Wed, May 7, 2008 at 11:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Luis,
To have your patch integrated, some changes are needed. First, we want to
default to 32bits sized arrays on 64bits machines, so your changes must
to allocate
an 8 Gb array.
On Thu, May 8, 2008 at 10:32 AM, Jonathan Pryor [EMAIL PROTECTED] wrote:
On Thu, 2008-05-08 at 08:45 -0300, Rodrigo Kumpera wrote:
We want to keep changes to a minimum
Understandable.
and we want to keep default array size 32bits.
This I still don't
On Thu, May 8, 2008 at 1:40 PM, Luis F. Ortiz [EMAIL PROTECTED] wrote:
On May 7, 2008, at 10:50 PM, Rodrigo Kumpera wrote:
Hi Luis,
To have your patch integrated, some changes are needed. First, we want to
default to 32bits sized arrays on 64bits machines, so your changes must
On Thu, May 8, 2008 at 1:54 PM, Luis F. Ortiz [EMAIL PROTECTED] wrote:
On May 7, 2008, at 10:50 PM, Rodrigo Kumpera wrote:
Hi Luis,
To have your patch integrated, some changes are needed. First, we want to
default to 32bits sized arrays on 64bits machines, so your changes must
Hi Jay,
It seens like you have found a regression in our remoting implementation as
your code from 1.2.4
should keep working.
Please fill a bug report with a complete test case and we will look at it.
http://www.mono-project.com/Bugs
Thanks,
Rodrigo
On Thu, May 8, 2008 at 6:22 PM, Jay L. T.
Hi Luis,
To have your patch integrated, some changes are needed. First, we want to
default to 32bits sized arrays on 64bits machines, so your changes must be
conditionally compiled. To help with that some changed to your patch are
due. Next are some comments about it:
Instead of replacing
Hi Eric,
Please, fill a bug report with a reproducible test case and we'll take a
look. http://www.mono-project.com/Bugs
Mark, the assert is related to generic sharing. Mind giving some light on
how to troubleshoot it?
Thanks,
Rodrigo
On Sun, May 4, 2008 at 11:39 PM, Eric Albright [EMAIL
Mono only inline very short methods. Right now methods must have a body at
most 20 bytes long.
2008/4/30 Alan McGovern [EMAIL PROTECTED]:
I recently started doing a bit of optimisation work on the
hashing/cryptography classes in mono. When working on the managed SHA256
class[1], i noticed
at 11:32 PM, Rodrigo Kumpera [EMAIL PROTECTED]
wrote:
Mono only inline very short methods. Right now methods must have a body
at most 20 bytes long.
2008/4/30 Alan McGovern [EMAIL PROTECTED]:
I recently started doing a bit of optimisation work on the
hashing/cryptography classes
You can add these tests to a subdir of mono/tests/ and require that such
compiler be instaled for them.
We can then ask Wade to install it on our windows build bot and add these
tests to the windows lanes.
On Mon, Apr 28, 2008 at 1:15 PM, Kornél Pál [EMAIL PROTECTED] wrote:
Hi,
From:
snip
It seems that only a small number of RGCTXs is ever used, and the ones
that are used could make do with 2 to 5 slots on average. For FSharp,
for instance, if we used an optimal allocation strategy (i.e. only
allocate RGCTXs if needed, only allocate as many slots as needed and
don't
virtual machine ? if so what are the specs ??? distro, gcc
version, options
thanks in advance ...
On 4/9/08, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
ReveIntech,
SVN head should be working, if it's not let us fix it. Please fill a bug
report with a repoducible test case
Hey Mark,
On Mon, Apr 14, 2008 at 11:58 AM, Mark Probst [EMAIL PROTECTED] wrote:
Hey Rodrigo!
Thanks for the feedback!
Isn't possible or better to do RGCTX free'ing at GC time? It would be
simpler, the hardest
part would be guarding against parking threads inside RGCTX related
code,
to do a major change in the JIT (switching to the
linear branch [1]) and unless you need to have your port working with
currently released version of mono, I suggest that you base everything on
Zoltan's linear-ir branch.
Rodrigo Kumpera
[1] http://www.mono-project.com/Linear_IL
On Mon, Apr 14, 2008
:
[EMAIL PROTECTED] *On Behalf Of *Rodrigo Kumpera
*Sent:* 14 April 2008 22:36
*To:* Gert Driesen
*Cc:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] verify.c compile error on cygwin
What's your gcc version? This is very odd.
On Mon, Apr 14, 2008 at 6:11 PM, Gert Driesen
ReveIntech,
SVN head should be working, if it's not let us fix it. Please fill a bug
report with a repoducible test case and I'll take a look at it.
Thanks,
Rodrigo
2008/4/9 ReveIntech [EMAIL PROTECTED]:
Hello can someone please tell me what is the last revision of the svn
revision that
Erven,
The ilasm mantainer now is Ankit Jain, you should ask him about that.
Besides that, the patch looks good and I don't see a reason why not
commiting it.
Rodrigo
On Mon, Apr 7, 2008 at 10:59 AM, Erven ROHOU [EMAIL PROTECTED] wrote:
Hello,
A month ago I proposed a patch to ilasm to
Joe,
I usually point all prefixes to ~/local/. This makes me avoid playing with
permissions as usually only the root user can write to /usr.
Rodrigo
On Mon, Apr 7, 2008 at 6:17 PM, Joe Audette [EMAIL PROTECTED] wrote:
Hi All,
Thanks for all the help. I installed a few more gcc related
Hi Paolo,
The attached patch adds the missing entry for
PerformanceCounterCategory::GetInstanceNames in icall-def.h. The AOT tests
are complaing about it. May I commit?
Cheers,
Rodrigo
Index: icall-def.h
===
--- icall-def.h
The attached patch make the loader report more accurate errors.
First, field_from_memberref now set a loader error when the type is not
found, this change will improve the exception message thrown and will make
things much simpler on the verifier side.
Second, method_from_memberref when the type
for the help. I realize that there are going
to be several problems like this in compiling as alpha is not one of the
targets.
travis miller
On Feb 10, 2008 5:25 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Travis,
The issue seens to be that memory barrier functions are not defined
PM, Travis Miller [EMAIL PROTECTED] wrote:
what irc channel are you on (server and channel). I would be very
interested in the community port.
travis miller
On Feb 11, 2008 9:49 AM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Travis,
Mono has a port to ALPHA supported by the comunity
Hi Travis,
The issue seens to be that memory barrier functions are not defined for the
alpha target.
Rodrigo
2008/2/10 Travis Miller [EMAIL PROTECTED]:
Hi, I am building mono 1.2.6 (latest stable) from source on a DEC Alpha
running Debian Etch. The problem I am having is duing the build
Hey,
The attached patch implements two missing visibility checks under mono. The
first is to fully check the visibility of the type. The second one is proper
family visibility checks, that require access to the static type of the
'this' parameter on stack. The current patch passes a full
Hey guys,
The attached patch adds BadImageException as one of the exceptions that can
make class loading fail. This should happen if the class super type token is
invalid.
Rodrigo.
Index: metadata/class.c
===
--- metadata/class.c
Hi Juraj,
@@ -326,7 +324,7 @@
Console.Error.WriteLine (WARNING: {0} is not
supported for now., el.FirstChild.LocalName);
continue;
}
-XmlElement cpElem = el.SelectSingleNode (cp) as
XmlElement;
+
Kumpera
*Gesendet:* Sonntag, 30. Dezember 2007 19:58
*An:* mono-devel-list@lists.ximian.com; Ankit Jain
*Betreff:* [SPAM] Re: [Mono-dev] [PATCH] Implement support for .emitbyte
directive onilasm
Forgot to attach EmityteInst.cs.
On Dec 30, 2007 4:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote
If the null test is not desired, a nested class can be used instead and the
cctor trampoline will be patched later by the runtime.
On Jan 2, 2008 2:24 PM, Andreas Nahr [EMAIL PROTECTED]
wrote:
The array initialization should also be done lazily and not in the static
constructor (should be
Hey,
While testing my last commit to mono I found a quite odd situation. What
happens is that once a method been inlined
and it fails due to a loader error, this error won't be clean up and it
could cause unwanted errors in mono_method_to_ir if it call mono_class_init.
The test I added,
Rodrigo Kumpera [EMAIL PROTECTED]
+
+ * EmiteByteInst.cs: added. Implements support
+ for the .emitbyte directive.
+
2007-10-09 Rodrigo Kumpera [EMAIL PROTECTED]
* MethodPointerTypeRef.cs (.ctor): generate
Index: ChangeLog
Forgot to attach EmityteInst.cs.
On Dec 30, 2007 4:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
The attached patch implements support for the .emitbyte directive. Please
review it.
Thanks,
Rodrigo
//
// Mono.ILASM.EmitByteIntr.cs
//
// Author(s):
// Rodrigo Kumpera ([EMAIL PROTECTED
Hey,
The attached patch adds an assert in both mono_metadata_decode_row(_col). I
think it's better to assert than access random data.
On the other hard, functions that decode metadata tables must perform such
checks and raise the apropriate error. The attached patch fixes that for
Acc
* Debug the server exception and track the reason of the current ARM issue
of #323747.
(dot done)
* Finish the exception handling tests of the verifier (partial)
* Work on the last 3 branch opcodes. (partial)
* Start working on delegate verification (not done)
While finishing the
Hey Mark,
@@ -762,7 +774,8 @@
THREAD_DEBUG (g_message (%s: Attached thread ID %G_GSIZE_FORMAT
(handle %p), __func__, tid, thread_handle));
-handle_store(thread);
+may_start = handle_store(thread);
+g_assert (may_start);
Why are you asserting here? Shouldn't the thread just
On Dec 13, 2007 4:31 PM, Mark Probst [EMAIL PROTECTED] wrote:
Hey!
@@ -762,7 +774,8 @@
THREAD_DEBUG (g_message (%s: Attached thread ID %G_GSIZE_FORMAT
(handle %p), __func__, tid, thread_handle));
-handle_store(thread);
+may_start = handle_store(thread);
+
Hey Paolo,
One thing missing are functions to probe the version/capabilities of the
library. Since the idea is to have the debugger use as much of the dbg api
as possible but falling back to the current code in case the lib doesn't
support specific stuff.
Rodrigo
On Dec 5, 2007 3:58 PM,
Ubuntu 6.06 server box due to dependency
failures.
Any other options?
On Dec 5, 2007 10:06 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
You can valgrind for unmanaged leak or heap buddy for managed leak.
http://www.mono-project.com/Debugging#Using_Valgrind_on_Mono
http://www.mono
Could you please fill a bug report on that, so we can track the issue? Add a
test case so it makes possible to have the bug tested.
On Nov 30, 2007 7:50 PM, Dave Ferguson [EMAIL PROTECTED] wrote:
We saw several seg faults when AppDomain.Unload was called in Mono on an
ARM processor. The
This week:
-Commited a patch for #335131
-Converted Mareks test into a regression test for #335131, creating it was
harder than I thought.
-Worked on #323747, got I patch sent to Paolo that fixes all soft-float
issues.
-Friday is celebration of death holiday
Next week:
-Fix more soft-float
Hi,
The attached patch optimize the imt thunk code. The optimization is to
exploit the fact that IP don't need to be preserved under a particular
situation.
The magic trampoline needs to retrieve the vtable pointer used by the call
site to patch it and this address might be stored in a scratch
Hey,
Attached are both the patch for IMT on ARM and a shell script I used to test
the changes.
The current design emit all contants after unconditional branches, this
works ok for bsearch entries as the distance until the next unconditional
branch is bound to less than 2kb (32 entries * 20 max
Hi Tyler,
I some coments about our patch, some are just minor details like formating
issues. You can read about our coding guidelines in
http://www.mono-project.com/Coding_Guidelines
For the options it's a good idea to create an enum in the c side. options
SPLIT_OPTIONS_REMOVE_EMPTY_ENTRIES, or
Hi,
The patch that changed the generic type definition to be the same instance
of the fully open instantiation introduced a small issue in the encoding of
types. This issue is quite subtle and gmcs produces it only on rare
situations.
If you use, for example: ILGenerator::Emit
Hey guys,
After talking with Hari I have come to a better solution. First, to fix the
case for non dynamic code I have reverted the changes of r80475 and r80445
as suggested by Hari. Reverting theses changes work because the issue was
the typebuilder issue pointer previowsly.
The new patch
Hey guys,
The patch if finally done and it works perfectly well against head. This
patch turned to be very different from what it started to look like and
fortunately this meant a reduction of more than an order of magnitude in its
size, from 3.000 lines to a bit more than 230.
To have the patch
Hey guys,
The patch if finally done and it works perfectly well against head. This
patch turned to be very different from what it started to look like and
fortunately this meant a reduction of more than an order of magnitude in its
size, from 3.000 lines to a bit more than 230.
To have the patch
Hi Eno,
Most of us had this issue, but it's a matter of making sure that you have a
matching mono binary with mscorlib. If you are running mono from the build
tree you must have MONO_PATH configured, otherwise, like my setup, just
'make install' it. If that doesn't help, you might need to
Hi Juraj,
I've posted a patch in the bug report.
Cheers,
Rodrigo
On 9/4/07, Juraj Skripsky [EMAIL PROTECTED] wrote:
This is bug http://bugzilla.ximian.com/show_bug.cgi?id=82695. I'm
posting it here because it never made it to the list (mono-bugs).
Bugzilla doesn't like me :-(.
Test
Hey Jb,
There are memory leaks when the exception message is built, it should free
the results of mono_method_full_name and mono_field_full_name. Besides these
issues, the patch looks good.
Rodrigo.
On 8/20/07, Jb Evain [EMAIL PROTECTED] wrote:
Folks,
As the title claims, here's a patch to
Hi Bill,
Below are some comments regarding your patch:
+
+return(ret);
+}
Don't use parentesis around the return value, it makes things harder to
read.
+int remain, n;
+int buf_size = st_src-st_blksize;
+char *buf = (char *) alloca (buf_size);
+
It's better to avoid alloca for
Hi,
I've just did a full bootstrap and System.Web doesn't compile any longer,
the attached patch fixes it. It's trivial fix, due to a #ifdef the name of
the static constructor of the class doesn't match it's name. May I commit
it?
Cheers,
Rodrigo
Index:
Hi,
Attached is a test for #82046. The thing with this test is that is plays
with custom attribute blobs and I'm not sure if doing this way is a good
idea.
Cheers,
Rodrigo
.assembly extern mscorlib
{
.ver 2:0:0:0
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
}
.assembly 'e'
{
Sorry, sent the wrong il file.
On 7/25/07, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi,
Attached is a test for #82046. The thing with this test is that is plays
with custom attribute blobs and I'm not sure if doing this way is a good
idea.
Cheers,
Rodrigo
.assembly extern mscorlib
{
.ver
Hey,
Attached is the patch with Raja's suggestion, it passes the regression
suite.
Rodrigo
On 7/24/07, Raja R Harinath [EMAIL PROTECTED] wrote:
Hi,
Paolo Molaro [EMAIL PROTECTED] writes:
On 07/23/07 Rodrigo Kumpera wrote:
The attached patch fix a memory leak in class.c, memory
Hi.
If you call Enum.GetNames for an enum which the basefield is not named
value__, mono crashes. The function ves_icall_get_enum_info should check
for static field and not the name. Attached are the patch to fix it and the
test used.
Cheers,
Rodrigo
Index: icall.c
Hey,
The attached patch fix a memory leak in class.c, memory is allocated in
mono_bounded_array_class_get and the copied in
mono_metadata_get_generic_inst, but never freed.
Cheers
Rodrigo
Index: class.c
===
--- class.c
Hey guys,
I haveve written a small patch to implement
TypeBuilder.UnderlyingSystemTypeform enum types, but for some reason
some tests are failing now and I can't
figure out why :(
With the attached patch applied the tests System.EnumTest.TestGetValues and
. It is there for people implementing their own type classes, see
System.Reflection.TypeDelegator for an example.
Zoltan
On 7/13/07, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hey guys,
I haveve written a small patch to implement
TypeBuilder.UnderlyingSystemType form enum types
Hi Paolo,
Shouldn't the other case that returns NULL in mono_class_create_from_typedef
use mono_class_set_failure as well? From now on I'll send patches using
.diff extension.
Thanks for the review!
Rodrigo
On 7/9/07, Paolo Molaro [EMAIL PROTECTED] wrote:
On 07/06/07 Rodrigo Kumpera wrote
Hey guys,
The attached patch fixes #82022. The fix is quite simple, it just checks if
the enum field is null and abort the loading process. But there are two
issues with this patch, first it could return a more informative message
about the problem and I'm not sure if it won't leak memory or
. This could lead to file descriptor exaction or sub-optimal system
performance. The best way is to let the application do manual resource
management. It's not that hard and produces better result. In your example,
it could have a queue that it's processed at specific times.
Cheers,
Rodrigo Kumpera
no modification.
Following patches will implement the TODO items.
Cheers,
Rodrigo Kumpera
access_check.patch
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Hey Guys!
The attached patch adds RadialGradientBrush to CreateObject() in
DependencyObject. It's a simple case statement added. Should I commit it?
While developing a button click effect for a desklet I've found this issue
and one related to the fact that if you add a Non System.Window.Visual
The attached fix fixes only the load address issue with constructors, the
paragraphs about class constructors said about this fact. I'll focus on the
access checks until we settle down the overlapping field issue. Enjoy your
vacations. :)
Cheers,
On 6/22/07, Rodrigo Kumpera [EMAIL PROTECTED
On 6/21/07, Paolo Molaro [EMAIL PROTECTED] wrote:
On 06/20/07 Rodrigo Kumpera wrote:
The attached patch does the following:
-implement all field load/store verifications
-fixes a small typo in a class.c comment
-function pointer validation now handles call convention
-fixed: brtrue/false
Hi everyone,
The attached patch does the following:
-implement all field load/store verifications
-fixes a small typo in a class.c comment
-function pointer validation now handles call convention
-fixed: brtrue/false flaged unmanaged pointers as invalid types (now just
flags as unverifiable)
601 - 700 of 713 matches
Mail list logo
