Re: [Mono-dev] Deadlock Detection in Mono Libraries

[Arun K]

Hi Pryor,

Thanks for the info and the reference.
The version of mono I used is 2.4.2.3 build 2008, but since our analysis is
at a preliminary stage, the version is of not much concern.

At the moment we only look at methods that are decorated with the
MethodImplOptions.
Synchronized attribute. Going further we would be looking at the
'lock(object)' constructs as well in our analysis. I will update you on my
future findings.
Thanks you once again.

-Arun


On Mon, Nov 8, 2010 at 8:03 PM, Jonathan Pryor  wrote:

> On Mon, 2010-11-08 at 07:35 +0530, Arun K wrote:
> > I am performing a static analysis on the mono 2.4.x libraries.
>
> 2.4.x?  How old!  (We're up to 2.8 now...)
>
> > The aim of this analysis is to detect potential deadlock scenarios
> > within the libraries. As a first step, I wanted to find if any
> > synchronized method invokes another synchronized method either
> > directly or eventually
>
> Thus, the *most* important question: How do you define "synchronized"?
>
> My guess is that your definition is a method with the attribute:
>
>[MethodImpl (MethodImplOptions.Synchronized)]
>
> If this is the case, the problem you're encountering is that this is
> explicitly counter to .NET documentation, e.g. [0, 1]:
>
>Generally, it is best to avoid locking on a public type, or on
>object instances beyond the control of your application. For
>example, lock(this) can be problematic if the instance can be
>accessed publicly, because code beyond your control may lock on
>the object as well. This could create deadlock situations where
>two or more threads wait for the release of the same object.
>
> .NET guidelines advocate declaring a *private* object instance and
> locking on that, instead of using Synchronized methods. [2]
>
> In short, if you see [MethodImpl (MethodImplOptions.Synchronized)],
> you're either looking at compatibility with .NET, or you're looking at a
> probable bug.
>
>  - Jon
>
> [0] http://msdn.microsoft.com/en-us/library/ms173179.aspx
> [1] 
> http://msdn.microsoft.com/en-us/library/ms182290(VS.80).aspx
> [2] My guess is that the only reason you can lock on System.Object and
> not some more restricted type is for Java compatibility...which is the
> ~same reason that .NET arrays are covariant.
>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SqlLiteeError when building XSP

[Gnanam]

Frankenspank wrote:
> 
> I downloaded the latest release of SQLite and sucessfully build/installed
> from source, but I
> am still getting the error.  Anyone have any ideas?
> 

Hi Frank,

I too have the same problem as yours.  Before I try out your other option of
removing 'test' directory, I want to upgrade SQLite3 and see for myself.

Can you provide me the download link location of SQLite latest version? Am
not able to find SQLite v3.5.0 for RHEL5/CentOS5.

Regards,
Gnanam
-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/SqlLiteeError-when-building-XSP-tp3027650p3032006.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] MonoDevelop freezes on resizing windows form

[Steve Ricketts]

Mono 2.6.4 openSuse 11.3

I'm trying to resize a windows form and when I run it in MonoDevelop
(2.2.2), it freezes the desktop.  The problem occurs when I reference
videoPanel.  I thought maybe I needed an Invoke here but it doesn't seem to
change anything.  Does anyone know why this is happening?

videoPanel.Invoke 
((MethodInvoker)delegate {

if (thisWidth * .75m > 
thisHeight) 

{

thisWidth = thisHeight 
* 1.32m;

videoPanel.Width = 
Convert.ToInt32(thisHeight);
  <--- problem
videoPanel.Height = 
this.Height;

videoPanel.Top = 0;

thisValue = 
Convert.ToDecimal(videoPanel.Width) / 2;

videoPanel.Left = 
Convert.ToInt32((thisWidth / 2) - thisValue);

}

else

{

thisHeight = thisWidth 
* .75m;

videoPanel.Width = this.Width;

videoPanel.Height = 
Convert.ToInt32(thisHeight);

videoPanel.Left = 0;

thisValue = 
Convert.ToDecimal(videoPanel.Height);

videoPanel.Top = 
Convert.ToInt32((thisHeight / 2) - thisValue);

}

});


designer.cs
// videoPanel

// 

this.videoPanel.Location = new System.Drawing.Point(1, 1);

this.videoPanel.Name = "videoPanel";

this.videoPanel.Size = new System.Drawing.Size(320, 240);

this.videoPanel.TabIndex = 2;

this.videoPanel.TabStop = false;


-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/MonoDevelop-freezes-on-resizing-windows-form-tp3031178p3031178.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

Re: [Mono-dev] Nullref when clearing TextBox that hasn't been shown yet

[darkgoob]

OK, I needed to go into /libgc and /eglib and run ./autogen.sh inside each to
pass the error about not finding the directory. 

However, now I encounter some new errors, while running make on mono's
source:


mv -f .deps/test_glib-slist.Tpo .deps/test_glib-slist.Po
gcc -DHAVE_CONFIG_H -I. -I..`pkg-config --cflags glib-2.0`
-DDRIVER_NAME=\"GLib\" -g -O2 -O0 -g -D_GNU_SOURCE -MT test_glib-sizes.o -MD
-MP -MF .deps/test_glib-sizes.Tpo -c -o test_glib-sizes.o `test -f 'sizes.c'
|| echo './'`sizes.c
sizes.c: In function ‘test_formats’:
sizes.c:20: error: expected ‘)’ before ‘G_GSIZE_FORMAT’
sizes.c:20: warning: spurious trailing ‘%’ in format
sizes.c: In function ‘test_ptrconv’:
sizes.c:32: error: ‘G_MAXINT32’ undeclared (first use in this function)
sizes.c:32: error: (Each undeclared identifier is reported only once
sizes.c:32: error: for each function it appears in.)
sizes.c:33: warning: cast to pointer from integer of different size
sizes.c:34: warning: cast from pointer to integer of different size
sizes.c:38: error: ‘G_MININT32’ undeclared (first use in this function)
sizes.c:39: warning: cast to pointer from integer of different size
sizes.c:40: warning: cast from pointer to integer of different size
sizes.c:45: warning: cast to pointer from integer of different size
sizes.c:46: warning: cast from pointer to integer of different size
sizes.c:51: warning: cast to pointer from integer of different size
sizes.c:52: warning: cast from pointer to integer of different size
sizes.c:57: warning: cast to pointer from integer of different size
sizes.c:58: warning: cast from pointer to integer of different size
sizes.c:63: warning: cast to pointer from integer of different size
sizes.c:64: warning: cast from pointer to integer of different size
sizes.c:69: warning: cast to pointer from integer of different size
sizes.c:70: warning: cast from pointer to integer of different size
sizes.c:75: warning: cast to pointer from integer of different size
sizes.c:76: warning: cast from pointer to integer of different size
make[4]: *** [test_glib-sizes.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Any help would be very appreciated. Thanks!
-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/Nullref-when-clearing-TextBox-that-hasn-t-been-shown-yet-tp3002455p3030441.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] unsubscribe

[Tim Nelson]

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

Re: [Mono-dev] Deadlock Detection in Mono Libraries

[Jonathan Pryor]

On Mon, 2010-11-08 at 07:35 +0530, Arun K wrote:
> I am performing a static analysis on the mono 2.4.x libraries.

2.4.x?  How old!  (We're up to 2.8 now...)

> The aim of this analysis is to detect potential deadlock scenarios
> within the libraries. As a first step, I wanted to find if any
> synchronized method invokes another synchronized method either
> directly or eventually

Thus, the *most* important question: How do you define "synchronized"?

My guess is that your definition is a method with the attribute:

[MethodImpl (MethodImplOptions.Synchronized)]

If this is the case, the problem you're encountering is that this is
explicitly counter to .NET documentation, e.g. [0, 1]:

Generally, it is best to avoid locking on a public type, or on
object instances beyond the control of your application. For
example, lock(this) can be problematic if the instance can be
accessed publicly, because code beyond your control may lock on
the object as well. This could create deadlock situations where
two or more threads wait for the release of the same object.

.NET guidelines advocate declaring a *private* object instance and
locking on that, instead of using Synchronized methods. [2]

In short, if you see [MethodImpl (MethodImplOptions.Synchronized)],
you're either looking at compatibility with .NET, or you're looking at a
probable bug.

 - Jon

[0] http://msdn.microsoft.com/en-us/library/ms173179.aspx
[1] http://msdn.microsoft.com/en-us/library/ms182290(VS.80).aspx
[2] My guess is that the only reason you can lock on System.Object and
not some more restricted type is for Java compatibility...which is the
~same reason that .NET arrays are covariant.


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

[Mono-dev] USB Support in Mono?

[Frank Cohen]

I need to develop software for a HID compliant device.  I would like it to
run on Linux/OS X if possible.  What level of support for USB does mono
have?

For the UI, I'd like to go Silverlight OOB.  The OOB app would talk to a
local sever that would handle all USB communications with the device, so
this chunk doesn't *have* to be mono, but it would be nice if it could be.
I saw that the moonlight project supports some Silverlight 4 stuff in the
previws, but the version on the site looks very old.
What are the plans for Moonlight and is OOB even supported?

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