Re: [Mono-dev] Mono 2.6.x

[Geoff Norton]

Matteo,

On 2010-02-08, at 4:57 AM, matteo tesser wrote:

> Hi Geoff,
> Is the well tested stable component you refer, public? can we help in testing?
> 

Yes, its the GC.  We've made the change in trunk which means that it will be in 
2.8 barring any problems.

> I only wan to say that Its a pity that this will not back-ported.
> Given this any change of running multi-thread apps is loss.
> I noticed that (at least in my case, a 3x performances boost can be
> obtained on Mac OS X also in cases where there only one background
> working thread  and an UI thread). Anyway I agree that is more
> important to have apps running slow that not running at all.
> 

2.6 is a stable supported release, I've discussed with the runtime team, and 
the consensus is that backporting a fundamental change to the GC into the 2.6 
branch is not worth the risks, it needs more time to incubate in trunk so that 
it can be included in 2.8.

> Finally a question: I noticed  when running autogen.sh I saw  the
> following line:
> 
> Parallel Mark: Disabled_Currently_Hangs_On_MacOSX
> 
> I assume that meaining of the word Hangs is: it goes too slow, and
> maybe this can solved by the   synchronization speedup.

No, hangs means it hangs and deadlocks the process.

> 
> I tried to force the use of parallel mark by compiling the trunk with
> the following option  --enable-parallel-mark, and I obtain the
> following  error on make, is this normal?
> 
> Making all in mini
> make  all-am
> ../../doltlibtool --quiet --tag=CC   --mode=link gcc -I../..
> -I../../libgc/include -D_REENTRANT
> -I/Users/teo/mono2.5/include/glib-2.0
> -I/Users/teo/mono2.5/lib/glib-2.0/include  -g -O2
> -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes
> -Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes
> -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings
> -export-dynamic  -sectcreate __TEXT __info_plist
> ../../mono/mini/Info.plist -pthread -o mono main.o libmono-static.la
> -L/Users/teo/mono2.5/lib -lgthread-2.0 -lglib-2.0 -lintl-lm
> -lpthread -lm
> Undefined symbols:
>  "_mono_gc_get_write_barrier", referenced from:
>  _decode_method_ref in libmono-static.a(aot-runtime.o)
> ld: symbol(s) not found

Are you still seeing this?

-g

> 
> Thanks,
> Matteo
> 
> On Wed, Feb 3, 2010 at 8:29 PM, Geoff Norton  wrote:
>> 
>> On 2010-02-03, at 2:27 AM, matteo tesser wrote:
>> 
>>> HI
>>> 
>>> The following bug has been fixed on the trunk, I would like it to be 
>>> backported:
>>> https://bugzilla.novell.com/show_bug.cgi?id=402833
>> 
>> This patch will not be backported, it changes the behaviour of well tested 
>> stable component in a major way with a serious chance of regressions.
>> 
>> Geoff
>> 
>> 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Carlos Alberto Cortez]

Hey!

I was taking a look and the issue is not reproducible in trunk, since
r145271 seems to fix it indirectly, by calling MonoIO.Write until *all* the
bytes have been written.

At least it fixes the very specific scenario described in the bug report,
and since that revision is expected to be backported, we should at least do
it.

Carlos.

2010/2/6 Miguel de Icaza 

> > > I've filed a somewhat nasty bug a few days back (you may lose your data
> > > if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813
> > >
> > > I'd really appreciate if someone could take a look at this.
> >
> > BUMP!  Doesn't anyone think it's a critical bug?
>
> The fix is trivial, the side effects are far reaching and any fix will
> require a careful review of those side effects.
>
> I would not expect a resolution any time soon.
>
> ___
> 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] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Alex Shulgin]

Leszek Ciesielski wrote:
> On Mon, Feb 8, 2010 at 4:34 PM, Alex Shulgin
>  wrote:
>>
>> Is there someone at Novell being paid to support Mono corlib?  I guess
>> there is or should be one...
>>
> 
> Yes, there are people paid to develop corlib and other Mono parts. If
> you do need commercial support, go ahead and pay for it:
> http://www.mono-project.com/Kickstart . This is, however, quite costly
> - on the other hand, it gives you the right to demand help. Without
> this - you are free to provide patches and tests - and if they are
> good, the will _eventually_ get merged. Just don't expect getting
> support for free - you either donate time or money. Just like in every
> other project.

Yay, this is not what I mean.

I always thought bugs (at least ones which are widely recognized as 
critical) ought to be fixed for free.  I'd expect people to pay for 
implementing new features, but fixing bugs... that logic eludes me.

Anyway, I'm not seriously bitten by the bug in question, so I let others 
decide if it's worth fixing. :)

--
Alex
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Alex Shulgin]

Sebastien Pouliot wrote:
> On Mon, 2010-02-08 at 17:07 +0200, Alex Shulgin wrote:
>> Sebastien Pouliot wrote:
>>> On Mon, 2010-02-08 at 15:07 +0200, Alex Shulgin wrote:
 BTW, couldn't this type of programming errors be caught by lint-like 
 tools for static code analysis?  
>>> Yes. Finding *potential* errors is easy. Automatically spotting errors
>>> that matters, like the above case, inside all the potential errors is
>>> much, much, much harder.
>> I agree, but ignored return value of close or fclose stands out as a 
>> plain error for me.  These should be easy to spot in the pile with 
>> relatively little effort.
>>
>> What I suggest, is that if this is ever going to be fixed, then all 
>> similar potentially problematic places should be also reviewed.
>>
>> [snip]
>>> You're welcome to contribute time to run static analysis tools, like
>>> Gendarme, on mono code base, spot real bugs and report them into
>>> bugzilla.
>> Sorry, I don't think I ever going to have time for this.
> 
> Congratulations, you just joined the club of "I know what's wrong but
> can't take the time to fix it". Note that your above suggestion which
> requires "relatively little effort" was emailed exclusively to members
> of the same club ;-)

Yeah, very insipring. ;)

OTOH, wasn't the "Critical" severity level designed exactly for people 
responsible for the component to postpone their current tasks and take 
some time to react on this new critical task? :)

Or is it simply going to be Unconfirmed forever?

Is there someone at Novell being paid to support Mono corlib?  I guess 
there is or should be one...

--
Alex
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Sebastien Pouliot]

On Mon, 2010-02-08 at 17:07 +0200, Alex Shulgin wrote:
> Sebastien Pouliot wrote:
> > On Mon, 2010-02-08 at 15:07 +0200, Alex Shulgin wrote:
> >>
> >> BTW, couldn't this type of programming errors be caught by lint-like 
> >> tools for static code analysis?  
> > 
> > Yes. Finding *potential* errors is easy. Automatically spotting errors
> > that matters, like the above case, inside all the potential errors is
> > much, much, much harder.
> 
> I agree, but ignored return value of close or fclose stands out as a 
> plain error for me.  These should be easy to spot in the pile with 
> relatively little effort.
> 
> What I suggest, is that if this is ever going to be fixed, then all 
> similar potentially problematic places should be also reviewed.
> 
> [snip]
> > You're welcome to contribute time to run static analysis tools, like
> > Gendarme, on mono code base, spot real bugs and report them into
> > bugzilla.
> 
> Sorry, I don't think I ever going to have time for this.

Congratulations, you just joined the club of "I know what's wrong but
can't take the time to fix it". Note that your above suggestion which
requires "relatively little effort" was emailed exclusively to members
of the same club ;-)

Sebastien

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Alex Shulgin]

Sebastien Pouliot wrote:
> On Mon, 2010-02-08 at 15:07 +0200, Alex Shulgin wrote:
>>
>> BTW, couldn't this type of programming errors be caught by lint-like 
>> tools for static code analysis?  
> 
> Yes. Finding *potential* errors is easy. Automatically spotting errors
> that matters, like the above case, inside all the potential errors is
> much, much, much harder.

I agree, but ignored return value of close or fclose stands out as a 
plain error for me.  These should be easy to spot in the pile with 
relatively little effort.

What I suggest, is that if this is ever going to be fixed, then all 
similar potentially problematic places should be also reviewed.

[snip]
> You're welcome to contribute time to run static analysis tools, like
> Gendarme, on mono code base, spot real bugs and report them into
> bugzilla.

Sorry, I don't think I ever going to have time for this.

--
Alex

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Fix for Type.GetMember returning private property of base class

[Eberhard Beilharz]

Bump!

On 01/28/2010 03:13 PM, Eberhard Beilharz wrote:
The patch adds a fix and a unit test for bug #574696 
 
where Type.GetMember returned a private property of the base class 
instead of nothing.


For a property Type.GetMember also checked the base classes for the 
desired property. It didn't do that for all the other cases like 
methods, events..., so I removed that recursion for the property case.


Please review and commit.

Thanks!
Eberhard


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
   
Index: mcs/class/corlib/System/Type.cs
===
--- mcs/class/corlib/System/Type.cs	(revision 149903)
+++ mcs/class/corlib/System/Type.cs	(working copy)
@@ -1050,18 +1050,11 @@
 }
 			}
 			if ((memberType & MemberTypes.Property) != 0) {
-PropertyInfo[] c;
-int count = l.Count;
-Type ptype;
+PropertyInfo[] c = GetProperties (bindingAttr);
 if (filter != null) {
-	ptype = this;
-	while ((l.Count == count) && (ptype != null)) {
-		c = ptype.GetProperties (bindingAttr);
-		foreach (MemberInfo m in c) {
-			if (filter (m, filterCriteria))
-l.Add (m);
-		}
-		ptype = ptype.BaseType;
+	foreach (MemberInfo m in c) {
+		if (filter (m, filterCriteria))
+			l.Add (m);
 	}
 } else {
 	c = GetProperties (bindingAttr);
Index: mcs/class/corlib/ChangeLog
===
--- mcs/class/corlib/ChangeLog	(revision 149903)
+++ mcs/class/corlib/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2010-01-28  Eberhard Beilharz 
+
+	* TypeTest.cs : Added test for bug #574696	
+	* Type.cs : Fix for bug #574696: don't recurse into base types in GetMember when
+	getting properties.
+	
 2009-12-03  Marek Habersack  
 
 	* corlib.dll.sources: added
Index: mcs/class/corlib/Test/System/TypeTest.cs
===
--- mcs/class/corlib/Test/System/TypeTest.cs	(revision 149903)
+++ mcs/class/corlib/Test/System/TypeTest.cs	(working copy)
@@ -3205,6 +3205,14 @@
 ++id;
 			}
 		}
+		
+		[Test] // Bug #574696
+		public void GetMember_DoesntReturnPrivatePropOfParent ()
+		{
+			Assert.AreEqual (1, typeof (Bar).GetMember ("PrivInst", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (0, typeof (Bar).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (1, typeof (Foo).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+		}
 
 #if NET_4_0
 		interface IGetInterfaceMap
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Sebastien Pouliot]

On Mon, 2010-02-08 at 15:07 +0200, Alex Shulgin wrote:
> Miguel de Icaza wrote:
> >>> I've filed a somewhat nasty bug a few days back (you may lose your data 
> >>> if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813
> >>>
> >>> I'd really appreciate if someone could take a look at this.
> >> BUMP!  Doesn't anyone think it's a critical bug?
> > 
> > The fix is trivial, the side effects are far reaching and any fix will
> > require a careful review of those side effects.
> > 
> > I would not expect a resolution any time soon.
> 
> Yep, pretty reasonable.  I'm not seriously bitten by this, though I'd 
> wish this didn't occur in the first place. :)
> 
> BTW, couldn't this type of programming errors be caught by lint-like 
> tools for static code analysis?  

Yes. Finding *potential* errors is easy. Automatically spotting errors
that matters, like the above case, inside all the potential errors is
much, much, much harder. 

In this case a return value is ignored. Spotting all ignored values is
not hard [1] but since this is something fairly common, even something
normal [2], it's hard to review every cases (i.e. reading thousands of
lines of "potential" defects logs and manually validating them) unless
they are "well known" patterns [3]. However most cases falls into the
"generally ok" category... (i.e. human eyes required)

[1] Gendarme has a rule for this - but will ignore many cases to remove
noise in the results.

[2] the return value of StringBuilder.Append is generally ignored,
unless it's chained with more Append calls, and that's perfectly legit
(and you don't want to be warned in those cases)

[3] Ignoring return value of calls like String.ToUpper is always bad
(that's an easy one ;-)


> Is any of them used regularly over the 
> mono codebase?

It's not a question of executing (or not, or how often) tools - but the
manpower to go thru all the results and decide which are true and must
be fixed versus the false ones (and the one not worth fixing or the ones
that will need a careful review before a simple fix can be committed).

You're welcome to contribute time to run static analysis tools, like
Gendarme, on mono code base, spot real bugs and report them into
bugzilla.

Sebastien

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Alex Shulgin]

Miguel de Icaza wrote:
>>> I've filed a somewhat nasty bug a few days back (you may lose your data 
>>> if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813
>>>
>>> I'd really appreciate if someone could take a look at this.
>> BUMP!  Doesn't anyone think it's a critical bug?
> 
> The fix is trivial, the side effects are far reaching and any fix will
> require a careful review of those side effects.
> 
> I would not expect a resolution any time soon.

Yep, pretty reasonable.  I'm not seriously bitten by this, though I'd 
wish this didn't occur in the first place. :)

BTW, couldn't this type of programming errors be caught by lint-like 
tools for static code analysis?  Is any of them used regularly over the 
mono codebase?

--
Cheers,
Alex
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono 2.6.x

[matteo tesser]

Hi Geoff,
Is the well tested stable component you refer, public? can we help in testing?

I only wan to say that Its a pity that this will not back-ported.
Given this any change of running multi-thread apps is loss.
I noticed that (at least in my case, a 3x performances boost can be
obtained on Mac OS X also in cases where there only one background
working thread  and an UI thread). Anyway I agree that is more
important to have apps running slow that not running at all.

Finally a question: I noticed  when running autogen.sh I saw  the
following line:

Parallel Mark: Disabled_Currently_Hangs_On_MacOSX

I assume that meaining of the word Hangs is: it goes too slow, and
maybe this can solved by the   synchronization speedup.

I tried to force the use of parallel mark by compiling the trunk with
the following option  --enable-parallel-mark, and I obtain the
following  error on make, is this normal?

Making all in mini
make  all-am
../../doltlibtool --quiet --tag=CC   --mode=link gcc -I../..
-I../../libgc/include -D_REENTRANT
-I/Users/teo/mono2.5/include/glib-2.0
-I/Users/teo/mono2.5/lib/glib-2.0/include  -g -O2
-fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings
-export-dynamic  -sectcreate __TEXT __info_plist
../../mono/mini/Info.plist -pthread -o mono main.o libmono-static.la
-L/Users/teo/mono2.5/lib -lgthread-2.0 -lglib-2.0 -lintl-lm
-lpthread -lm
Undefined symbols:
  "_mono_gc_get_write_barrier", referenced from:
  _decode_method_ref in libmono-static.a(aot-runtime.o)
ld: symbol(s) not found

Thanks,
Matteo

On Wed, Feb 3, 2010 at 8:29 PM, Geoff Norton  wrote:
>
> On 2010-02-03, at 2:27 AM, matteo tesser wrote:
>
>> HI
>>
>> The following bug has been fixed on the trunk, I would like it to be 
>> backported:
>> https://bugzilla.novell.com/show_bug.cgi?id=402833
>
> This patch will not be backported, it changes the behaviour of well tested 
> stable component in a major way with a serious chance of regressions.
>
> Geoff
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Miguel de Icaza]

> > I've filed a somewhat nasty bug a few days back (you may lose your data 
> > if you trigger it): https://bugzilla.novell.com/show_bug.cgi?id=575813
> > 
> > I'd really appreciate if someone could take a look at this.
> 
> BUMP!  Doesn't anyone think it's a critical bug?

The fix is trivial, the side effects are far reaching and any fix will
require a careful review of those side effects.

I would not expect a resolution any time soon.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list