Hi..
I've found an underlying reason of that bug and prepared a test case. You
can find the code and a description of a problem here:
http://bugzilla.xamarin.com/show_bug.cgi?id=3004
Now I'm trying to solve this issue but I need some information about ideas
which stands behind the expression
Hello,
Unfortunately that problem still exists and probably it was not related to
that one linked by Zoltan. Still cannot provide a way to reproduce it but
it's gone after switching mono back to the 2.8 version (it's build from last
commit in 2.8 branch). Maybe this information can help to
krlm wrote:
Hello,
Unfortunately that problem still exists and probably it was not related to
that one linked by Zoltan. Still cannot provide a way to reproduce it but
it's gone after switching mono back to the 2.8 version (it's build from
last commit in 2.8 branch). Maybe this
Hi jmalcolm,
Thanks for your reply, I forgot to mention (or I did it in previous posts).
I always compile the latest stable branch so I'm sure that problem still
exist in 2.10 branch.
BTW, No, I've not added the problem into Bugzilla, I thought I'd need to
gather more information.
Best
Hi Marcin,
I think it'd be OK to add a Bugzilla entry and point to this ML
thread, even if more information is still needed.
Regards,
Alex
2011/6/20 krlm kr...@poczta.onet.pl:
Hi jmalcolm,
Thanks for your reply, I forgot to mention (or I did it in previous posts).
I always compile the
Hello,
I'm afraid this wasn't our case, because after updating mono to version
2.10.2 (from branch not a tarball) we still get reports that stack overflow
occurs.
Does anybody have any idea how can I find cause of this problem?
Best Regards,
Pawel
Zoltan Varga wrote:
Hi,
This was
Hi,
I'd like to provide some additional data on this problem.
I added some code into Equals method of System.MulticastDelegate that uses
Object.ReferenceEquals(this,this.prev) to check whether this == this.prev, I
used it instead of this.Equals(this.prev) because we suspected that original
Hi,
This was probably caused by:
https://bugzilla.novell.com/show_bug.cgi?id=687902
https://bugzilla.novell.com/show_bug.cgi?id=687902which is now fixed.
Zoltan
On Mon, May 2, 2011 at 2:45 AM, pwo szy...@onet.pl wrote:
Hi,
I'd like to provide some additional data on
W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza mig...@novell.com
napisał:
While another one is doing an equality test, the state is half-built.
The way you could instrument this is to rewrite that routine to not be
recursive, but instead to be iterative, and have a maximum count,
Aren't event handler methods emitted with a [synchronized] attribute by
default which would prevent this issue? You can check by disassembling the
IL and seeing if its there.
Alan
On 4 Apr 2011 14:55, kr...@poczta.onet.pl wrote:
W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent this issue? You can check by
disassembling the IL and seeing if its there.
They are synchronized as long as you don't replace the default
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier gonzalo.m...@gmail.com
wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent this issue? You can check by
disassembling the IL and seeing
On Mon, Apr 4, 2011 at 10:37 PM, kr...@poczta.onet.pl wrote:
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier gonzalo.m...@gmail.com
wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent
On Mon, 2011-04-04 22:41:47 nekresh nekr...@gmail.com wrote:
On Mon, Apr 4, 2011 at 10:37 PM, kr...@poczta.onet.pl wrote:
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier
gonzalo.m...@gmail.com wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods
Hey,
Well the other thing is that the delegate class is supposed to be
immutable. Therefore it should be impossible to produce a corrupt
delegate through multithreaded access as any modification to a
delegate instance results in a new copy of the delegate (with
modification) being created, just
Hi Marcin,
I very much agree with you here. Even searching for assignments to
prev, doesn't yield anything too suspicious (except for where a local
variable overrides the scope of the class-level field!). All
assignments *appear* to be clones, which is okay.
Can you squeeze out any more
I've found an issue in my ASP.NET application when it's running under heavy
load. It throws an exception like that: http://pastebin.com/DRAYVM0F and
then the whole application is down, i've to restart apache/mod-mono-server.
It's running under mono 2.10.1, apache2 and mod-mono. On IIS/MS.NET
Hi Tom,
Thanks for your reply. I've also just took a look on the MulticastDelegate
implementation and on the CombineImpl method but I cannot see how to make
that this.prev to be equals to this. Maybe the issue lies in the RemoveImpl
method/KMP? I'll try to debug this step by step. Thanks in
Hello,
I've found an issue in my ASP.NET application when it's running under heavy
load. It throws an exception like that: http://pastebin.com/DRAYVM0F and
then the whole application is down, i've to restart apache/mod-mono-server.
It's running under mono 2.10.1, apache2 and mod-mono. On
Hello,
After a quick glance over the implementation of MulticastDelegate, it
looks like it could be a bug. But I'm not too sure.
To me, it looks like the bug is here, line 96:
return this.prev.Equals (d.prev);
If 'this.prev' is == 'this', then, this would cause an infinite
recursion, as the
20 matches
Mail list logo
