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.)

[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] [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] [Bug 575813] FileStream doesn't handle errors on Close (disk full, generic error, etc.)

[Alex Shulgin]

Carlos Alberto Cortez wrote:
> I will take a look at it in the next days.

OK, thanks for that! :)

--
Alex

> 2010/2/5 Alex Shulgin  <mailto:alexander.shul...@yessoftware.com>>
> 
> Alex Shulgin wrote:
>  > Hi,
>  >
>  > 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?
> 
> --
> Alex
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> <mailto: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]

Alex Shulgin wrote:
> Hi,
> 
> 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?

--
Alex

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

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

[Alex Shulgin]

Hi,

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.

--
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] mkbundle + System.Text.GetEncoding = NotSupportedException

[Alex Shulgin]

Robert Jordan wrote:
> Hi,
> 
> Alex Shulgin wrote:
>> I've tried adding -r:I18N or -r:I18N.Other when compiling with gmcs, but 
>> it mkbundle still doesn't pick it up and the end result is the same.
> 
> Since these assemblies are loaded via reflection, you must
> bundle them manually:
> 
> mkbundle [options] your-assemblies $mono-prefix/lib/mono/2.0/I18N*.dll

Ah, thanks--that solved it! :)

--
Alex

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

[Mono-dev] mkbundle + System.Text.GetEncoding = NotSupportedException

[Alex Shulgin]

Hi all,

In the following scenario with mono-2.4 I get "CodePage XXX not 
supported" when trying to run mkbundle-d test program on a 'clean' box 
(w/o mono installed):

$ cat codepage.cs
using System;
using System.Text;

namespace test {
public static class Program {
public static void Main() {
Console.WriteLine("Hello, world.");

Encoding enc = Encoding.GetEncoding(1251);
Console.WriteLine("enc: {0}", enc);
}
}
}

$ gmcs codepage.cs

$ mkbundle2 --deps --static codepage.exe -o codepage
OS is: Linux
Note that statically linking the LGPL Mono runtime has more licensing 
restrictions than dynamically linking.
See http://www.mono-project.com/Licensing for details on licensing.
Sources: 1 Auto-dependencies: True
embedding: /home/alexs/tmp/mkbundle/codepage.exe
embedding: /usr/local/lib/mono/2.0/mscorlib.dll
Compiling:
as -o temp.o temp.s
cc -o codepage -Wall `pkg-config --cflags mono` temp.c  `pkg-config 
--libs-only-L mono` -Wl,-Bstatic -lmono -Wl,-Bdynamic `pkg-config 
--libs-only-l mono | sed -e "s/\-lmono //"` temp.o
Done

$ ./codepage
Hello, world.
enc: I18N.Other.CP1251

This is OK.  Now I want to emulate 'clean' box by removing all lib files 
(I have mono in /usr/local):

$ ( cd /usr/local; sudo mv lib lib~ )

$ ./codepage
Hello, world.

Unhandled Exception: System.NotSupportedException: CodePage 1251 not 
supported
   at System.Text.Encoding.GetEncoding (Int32 codepage) [0x0]
   at test.Program.Main () [0x0]

So, I've identified that cp1251 lives in I18N.Other.dll.  How do I make 
mkbundle package that assembly?

I've tried adding -r:I18N or -r:I18N.Other when compiling with gmcs, but 
it mkbundle still doesn't pick it up and the end result is the same.

Help please!

--
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-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

[Alex Shulgin]

Sebastien Pouliot wrote:
> 
> Please open a bug report on bugzilla.novell.com and attach your test
> case.

https://bugzilla.novell.com/show_bug.cgi?id=551009

>> On my Linux box it crashes all the time.  I get a wide variety of errors 
>> from gdb stacktraces with SIGSEGV or SIGABRT in the end, to SIGILL with 
>> .Net stack trace.
>>
>> Uncommenting these lock {} lines in the ThreadProc helps, but not an 
>> option for my real app, as there's simply no single place a lock could 
>> be added.
>>
>> I've also tried writing some code in plain C which links to libgdiplus 
>> directly: see `threads-gdiplus.c'.  It happily crashes just like the C# 
>> version.
> 
> Most of System.Drawing is only a small wrapper abound libgdiplus (or GDI
> + under Windows). Any bug will likely be inside libgdiplus so it's
> "normal" (i.e. expected) that you get the same behavior.

Yes, it's what I expected.  Just thought it might be helpful in 
debugging the problem.  Attached this to the bug too.

>> My tests show that even using unsynchronized GdipGetImageGraphicsContext 
>> / GdipDeleteGraphics (no fonts stuff touched) can easily lead to crashes.
>>
>>  From what I've seen, cairo seems to be thread-safe: see attached[1] 
>> `cairo-multi-thread-text.c'.
> 
> It's thread-safe as long as everything is created and executed in the
> same thread. Otherwise it would not be safe-thread (just like .net and
> most libraries are).

This is actually what I meant by thread-safe here. :)

I'd expect any library not to crash under similar circumstances as long 
as it doesn't use global variables or, if so, does ensure proper locking 
around them.

--
Regards,
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-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

[Alex Shulgin]

Alex Shulgin wrote:
> Hi all,
> 
> Is System.Drawing by any means thread-safe?
> 
> Can I create some threads, create a Graphics object in each of them and 
> then work with it from within that thread?  Is this supposed to work or 
> am I doing something really stupid here?

Oh, forgot to mention that I've tested this on both 2.4 and latest 
available 2.6.  The results are the same.

--
Alex

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

[Mono-dev] Is System.Drawing (libgdiplus) thread-safe?

[Alex Shulgin]

Hi all,

Is System.Drawing by any means thread-safe?

Can I create some threads, create a Graphics object in each of them and 
then work with it from within that thread?  Is this supposed to work or 
am I doing something really stupid here?


I ask because I've noticed random crashes in a WinForms app on OS X (but 
it happens on Linux too).  Most of the time it crashes in 
System.Drawing.Graphics' DrawString or MeasureString methods and seems 
to occur then a background worker thread is working in parallel with UI 
thread.


I've tried to do a stress-test of System.Drawing in a sample 
multi-threaded program.  See attached `test-multi-threaded-drawing.cs'.


On my Linux box it crashes all the time.  I get a wide variety of errors 
from gdb stacktraces with SIGSEGV or SIGABRT in the end, to SIGILL with 
.Net stack trace.


Uncommenting these lock {} lines in the ThreadProc helps, but not an 
option for my real app, as there's simply no single place a lock could 
be added.


I've also tried writing some code in plain C which links to libgdiplus 
directly: see `threads-gdiplus.c'.  It happily crashes just like the C# 
version.


My tests show that even using unsynchronized GdipGetImageGraphicsContext 
/ GdipDeleteGraphics (no fonts stuff touched) can easily lead to crashes.


From what I've seen, cairo seems to be thread-safe: see attached[1] 
`cairo-multi-thread-text.c'.


Also, there's a few locking used around thread-unsafe fontconfig calls 
in libgdiplus itself.  I didn't examined the whole code, so there's 
possibly other places in it missing locking primitives.


I would appreciate any help on this subject!

--
Regards,
Alex
[1] originally found in the cairo bugzilla for a few-years-old bug; my 
sligthly enhanced version
/* gmcs test-multi-threaded-drawing.cs -r:System.Drawing,System.Windows.Forms */
using System;
using System.Text;
using System.Drawing;
using System.Windows.Forms;
using System.Threading;

namespace test {
	public class MainForm : Form {
		private static int threadCount = 0;

		private object consoleLock = new Object();
		private object hwndLock = new Object();

		public static void Main(string[] args) {
			threadCount = args.Length == 0 ? 6 : int.Parse(args[0]);

			Application.Run(new MainForm());
		}

		protected override void OnLoad(EventArgs e) {
			base.OnLoad(e);

			for (int i = 0; i < threadCount; ++i) {
Thread t = new Thread(ThreadProc);
t.Start(i);
			}
		}

		void ThreadProc(object data) {
			int threadnum = (int) data;

			Random rnd = new Random((int) DateTime.Now.Ticks);
			int count = rnd.Next(250, 1000);
			lock (consoleLock) {
Console.WriteLine("thread{0} start: {1}", threadnum, count);
			}

			for (int i = 0; i < count; ++i) {
string str = CreateRandomString(rnd);

using (Graphics g = GetGraphicsForMeasurement()) {
	using (Font font = CreateRandomFont(rnd)) {
		//lock (hwndLock) {
		SizeF sz = g.MeasureString(str, font);

		using (Bitmap bmp = new Bitmap((int) sz.Width, (int) sz.Height)) {
			using (Graphics gfx = Graphics.FromImage(bmp)) {
using (Brush b = Brushes.Red) {
	gfx.DrawString(str, font, b, new PointF(0f, 0f));
}
			}
		}
		//}
	}
}
			}

			lock (consoleLock) {
Console.WriteLine("thread{0} done", threadnum);
			}
		}

		string CreateRandomString(Random rnd) {
			int len = 1 + rnd.Next(60);
			StringBuilder sb = new StringBuilder(len);
			for (int j = 0; j < len; ++j) {
int ch = (rnd.Next() & 1) == 1 ? 0x41 : 0x61; // 'A' or 'a'
sb.Append(Char.ConvertFromUtf32(ch + rnd.Next(26)));
			}
			return sb.ToString();
		}

		Graphics GetGraphicsForMeasurement() {
#if NO_GRAPHICS_FROM_HWND
			Bitmap tmp = new Bitmap(1, 1);
			return Graphics.FromImage(tmp);
#else
			Graphics g;
			lock (hwndLock) {
g = Graphics.FromHwnd(this.Handle);
			}
			return g;
#endif
		}

		Font CreateRandomFont(Random rnd) {
			return new Font("Sans", (int) (8 + rnd.NextDouble()*10));
		}
	}
}
/* gcc `pkg-config --cflags --libs cairo` -lpthread multi-thread-text.c -o multi-thread-text */

/*
 * Copyright © 2005 Red Hat, Inc.
 *
 * Permission to use, copy, modify, distribute, and sell this software
 * and its documentation for any purpose is hereby granted without
 * fee, provided that the above copyright notice appear in all copies
 * and that both that copyright notice and this permission notice
 * appear in supporting documentation, and that the name of
 * Red Hat, Inc. not be used in advertising or publicity pertaining to
 * distribution of the software without specific, written prior
 * permission. Red Hat, Inc. makes no representations about the
 * suitability of this software for any purpose.  It is provided "as
 * is" without express or implied warranty.
 *
 * RED HAT, INC. DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
 * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 * FITNESS, IN NO EVENT SHALL RED HAT, INC. BE LIABLE FOR ANY SPECIAL,
 * INDIRECT OR CONSEQUENTIA

Re: [Mono-dev] [PATCH] detect sse4a for simd intrinsics.

[Alex Shulgin]

Jerry Maine - KF5ADY wrote:
> Here is the patch I wrote to detect sse4a, it is released under MIT/X11.
> 
> Comments questions? [Yes, I tested it the best I could on my AMD machine
> which doesn't support sse4a.]

Obviously, you forgot the patch itself.

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

Re: [Mono-dev] Fwd: Missing configure file when I check out from svn

[Alex Shulgin]

Krishna Kishore wrote:
> 
> Hi,
> 
> I checked out using
>   svn co svn://anonsvn.mono-project.com/source/trunk/moon 
> 
>   
> After checking out, I am trying to configure, build and install. 
> But, I did not find configure file in the directory.  How do I get it?
>Please let me know.

$ ./bootstrap

or

$ sh autogen.sh

--
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 requires /proc to be mounted

[Alex Shulgin]

Jonathan Pryor wrote:
> On Thu, 2009-09-24 at 12:55 -0400, Ryan Bair wrote:
>> Chroots commonly have bind mounts to /proc and /dev.  ie mount -o
>> bind /proc /path/to/chroot/proc
>>
>> I'm not sure if Mono on Linux depends on proc being there or not, but
>> there is one really easy way to find out.
> 
> And the answer is...it depends.  OS X doesn't have /proc, so (1) Mono
> itself will run w/o /proc, but...  (2) some parts of the class library
> will NOT work.  For example, Process.GetProcesses() will generate a
> NullReferenceException, because EnumProcesses() requires /proc (see
> mono/io-layer/processes.c).
> 
> So it depends entirely on which parts of the class library you're using.

I'm on Linux.

The question is: is it worth trying to disable startup check on 
availability of /proc and see what happens next?

I'm concerned on security so allowing full /proc in chroot is not very 
pleasant for me.

I see these usage cases of /proc in mono:

1. /proc/self/maps is used by libgc/os_dep.c to find writable data segments.

=> I can try to set GC_DONT_GC, since my app is meant to run for a few 
seconds and exit.

2. /proc/self/exe is used in mono/metadata/assembly.c to set root dirs.

=> I use bundled assemblies, so this one can be possibly ignored.

3. /proc/cpuinfo is used in libgc/pthread_support.c to determine the 
number of processors.

=> This one can be easily fooled with cat /proc/cpuinfo 
 >/path/to/chroot/proc/cpuinfo.

So I think I'll give it a try. :)

--
Regards,
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 requires /proc to be mounted

[Alex Shulgin]

Ryan Bair wrote:
> Chroots commonly have bind mounts to /proc and /dev.  ie mount -o bind 
> /proc /path/to/chroot/proc

This is what I do to some extent currently.  For my app it sufficed to 
MAKEDEV null, tty and urandom.

> I'm not sure if Mono on Linux depends on proc being there or not, but 
> there is one really easy way to find out.

Obviously, it does. :)

The subject line "Mono requires /proc to be mounted." is printed on 
terminal whenever you try to run bundled mono app in chroot w/o /proc 
(and the process aborts).

--
Alex

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

[Mono-dev] Mono requires /proc to be mounted

[Alex Shulgin]

Hi,

I'm trying to use mono in a (surprise, surprise!) chrooted environment.

I see there're tons of references to /proc in the code.  Am I obliged to 
mount /proc wholesale or there are some options?

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

Re: [Mono-dev] mkbundle + app.config

[Alex Shulgin]

Alex Shulgin wrote:
> Alex Shulgin wrote:
>> Later, then ConfigurationManager is trying to load .config file for the 
>> assembly, it uses the fake name and naturally doesn't see a file named 
>> data-xxx.config near the bundled assembly.
>>
>> I don't think it's possible to make use of bundled assemblies 
>> information buried in mono internals (mono/metadata/assebmbly.c).
> 
> I mean it's not possible to use that info _from 
> System.ConfigurationManager_.

There's also a problem with embedding machine config.

It was reported before and fixed[1], but now it's broken again.

The below patch is enough to resolve the problem for me.

--
Regards,
Alex

[1] https://bugzilla.novell.com/show_bug.cgi?id=325022


Index: mcs/class/System.Configuration/System.Configuration/Configuration.cs
===
--- 
mcs/class/System.Configuration/System.Configuration/Configuration.cs 
(revision 141143)
+++ 
mcs/class/System.Configuration/System.Configuration/Configuration.cs 
(working copy)
@@ -449,10 +449,14 @@
if (String.IsNullOrEmpty (streamName))
return true;

-   if (!File.Exists (streamName))
-   return false;
+   // Don't check if file exists here as this will cause
+   // bundled machine config to be skipped on machines w/o
+   // mono installed.

-   Stream stream = stream = system.Host.OpenStreamForRead 
(streamName);
+   //if (!File.Exists (streamName))
+   //  return false;
+
+   Stream stream = system.Host.OpenStreamForRead 
(streamName);
using (XmlTextReader reader = new ConfigXmlTextReader 
(stream, 
streamName)) {
ReadConfigFile (reader, streamName);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mkbundle + app.config

[Alex Shulgin]

Alex Shulgin wrote:
> 
> Later, then ConfigurationManager is trying to load .config file for the 
> assembly, it uses the fake name and naturally doesn't see a file named 
> data-xxx.config near the bundled assembly.
> 
> I don't think it's possible to make use of bundled assemblies 
> information buried in mono internals (mono/metadata/assebmbly.c).

I mean it's not possible to use that info _from 
System.ConfigurationManager_.

--
Alex

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

[Mono-dev] mkbundle + app.config

[Alex Shulgin]

Hi,

There is a problem when using mkbundle together with 
System.ConfigurationManager: namely, app.config file is not loaded and 
you get empty configuration values, e.g. from AppSettings.

This has been reported before[1], but no one seems to get it fixed.

I've traced the problem down to mono_image_open_from_data_full() in 
mono/metadata/image.c which gives newly loaded images a unique names 
like this: data-0x012345678

Later, then ConfigurationManager is trying to load .config file for the 
assembly, it uses the fake name and naturally doesn't see a file named 
data-xxx.config near the bundled assembly.

I don't think it's possible to make use of bundled assemblies 
information buried in mono internals (mono/metadata/assebmbly.c).

So the other way round which worked for me is passing the bundled 
assembly name along with data to mono_image_open_from_data_full() to use 
instead of fake one (and after placing a copy of app.config already 
bundled in the binary).

Drawbacks?  Comments?

--
Regards,
Alex

[1] http://go-mono.com/forums/#nabble-td20406123|a21214922
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Simple implementation of network interface properties for Mac OS X

[Alex Shulgin]

Alan McGovern wrote:
> Hey,
> 
[snip]
> --
> Alex
> PS: is there more appropriate way to increment IntPtr value w/o
> using ToInt64()?
> 
> 
> You could use a loop and Marshal.ReadByte (IntPtr ptr, int offset);

For this purpose, yes.  But what would you do if amount of data to read 
is, say megabyte or more?

--
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] Simple implementation of network interface properties for Mac OS X

[Alex Shulgin]

Alex Shulgin wrote:

Alex Shulgin wrote:

Hi,

In the current version System.Net.NetworkInformation.NetworkInterface 
provides limited information about network interfaces on the system 
(their names only).


The attached patch adds support for NetworkInterfaceType and 
GetPhysicalAddress() on Mac OS.


Oops, I've almost forgot about IPv6... and missed the added file 
MacOsNetworkInterfaceMarshal.


Please see the fixed patch instead.


This worked fine, until one user reported a crash on Array.Copy in 
NetworkInformation.MacOsNetworkInterface.ImplGetAllNetworkInterfaces(). 
 I traced this down to that I believe is a problem with non-standard 
length interface name: thus the 12-byte buffer sockaddr_dl.sdl_data is 
not enough.


I've noticed that sockaddr_dl contains sdl_len member which holds the 
length of the whole sockaddr structure.  With that we can use 
Marshal.Copy instead of Array.Copy to access data past default 12-byte 
data array.  A patch against trunk is attached.


I didn't have a chance to try it with the problematic user, but still 
would like someone to review the patch and comment on it.


--
Alex
PS: is there more appropriate way to increment IntPtr value w/o using 
ToInt64()?
Index: System.Net.NetworkInformation/NetworkInterface.cs
===
--- System.Net.NetworkInformation/NetworkInterface.cs	(revision 137150)
+++ System.Net.NetworkInformation/NetworkInterface.cs	(working copy)
@@ -480,7 +480,8 @@
 			MacOsStructs.sockaddr_dl sockaddrdl = (MacOsStructs.sockaddr_dl) Marshal.PtrToStructure (addr.ifa_addr, typeof (MacOsStructs.sockaddr_dl));
 
 			macAddress = new byte [(int) sockaddrdl.sdl_alen];
-			Array.Copy (sockaddrdl.sdl_data, sockaddrdl.sdl_nlen, macAddress, 0, macAddress.Length);
+			// copy `sdl_alen' bytes from `sdl_data + sdl_nlen'
+			Marshal.Copy ((IntPtr)(addr.ifa_addr.ToInt64 () + 8 + sockaddrdl.sdl_nlen), macAddress, 0, macAddress.Length);
 			index = sockaddrdl.sdl_index;
 
 			int hwtype = (int) sockaddrdl.sdl_type;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [BUMP] Re: Alpha blending in libgdiplus (call for testers)

[Alex Shulgin]

Alex Shulgin wrote:
> Hi,
> 
> Recently a whole set of issues in libgdiplus related to alpha blending 
> was discovered.  They are summarized in this bug report: 
> https://bugzilla.novell.com/show_bug.cgi?id=495516

BUMP!

Has anyone tried the patch?

Please reply if you have tried but have problems/have no time to 
report/etc.  Any feedback is very much appreciated!

--
Regards,
Alex

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

[Mono-dev] Alpha blending in libgdiplus (call for testers)

[Alex Shulgin]

Hi,

Recently a whole set of issues in libgdiplus related to alpha blending 
was discovered.  They are summarized in this bug report: 
https://bugzilla.novell.com/show_bug.cgi?id=495516

Some important information can be found in the original mailing list 
thread[1].  In particular, motivation behind the changes is described[2] 
in detail there.

In short: libgdiplus uses cairo to do drawing; cairo uses special PARGB 
format for pixels representation; libgdiplus tries to hide this fact 
from clients; this doesn't work out.

There's currently a patch to solve the issues, but it didn't see much 
testing.

If you are an active mono user (think System.Windows.Forms, 
System.Drawing) or you are porting existing code to mono, or you just 
feel adventurous then you can help by trying libgdiplus from SVN (or 
latest released tarball[3]) with the patch.

Please, if you wish for a brighter future for mono and have some spare 
time, try the following (instructions for Ubuntu):

# Install libs & tools needed to compile libgdiplus.
$ sudo apt-get build-dep libgdiplus

# Bootstrap build environment.  Add --prefix=/usr to replace version
# from package upon install (not needed if you use mono and class
# libraries from SVN, like me.)
~/src/mono/trunk/libgdiplus$ sh autogen.sh

# Apply the patch, download it first from bug report above.
$ patch -p0 https://bugzilla.novell.com/attachment.cgi?id=291608

It is generally wise to run the tests before and after applying the 
patch to see if there's any difference (you can always use patch -R to 
revert it).

If tests are looking good, please try do you daily stuff with mono and 
report any problems you think were introduced by the patch.  If you have 
some unit tests in your apps--please run them as well.

With your help I hope we can catch potential problems with the patch 
before the next mono release.

--
Happy hacking!
Alex

[1] http://go-mono.com/forums/#nabble-to22931264
[2] http://go-mono.com/forums/#nabble-p23232056
[3] http://ftp.novell.com/pub/mono/sources/libgdiplus/libgdiplus-2.4.tar.bz2
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Debugging Win32Exception on Process.Start

[Alex Shulgin]

APS wrote:
> Hi,
> 
> launching a java process with Process.Start I obtain an error like this:
> 
> System.ComponentModel.Win32Exception: ApplicationName='"/usr/bin/java"', 
> CommandLine='-Xms20M -Xmx100M -Xincgc -jar "/home/monousr/myjar.jar" 
> param1 param2 param3 param4 "/home/monousr/"', CurrentDirectory=''
>   at System.Diagnostics.Process.Start_noshell 
> (System.Diagnostics.ProcessStartInfo startInfo, 
> System.Diagnostics.Process process) [0x00247]
>   at System.Diagnostics.Process.Start_common 
> (System.Diagnostics.ProcessStartInfo startInfo, 
> System.Diagnostics.Process process) [0x00096]
>   at System.Diagnostics.Process.Start () [0x0002c]
> 
> Launching manually the same application with same params works. I would 
> like to understand how to solve the problem, how can I see the output of 
> the process or some log that explain better what is the problem? or you 
> already know what the problem could be?

May be it's extra quotation marks around /usr/bin/java?..

--
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] Simple implementation of network interface properties for Mac OS X

[Alex Shulgin]

Alex Shulgin wrote:

Hi,

In the current version System.Net.NetworkInformation.NetworkInterface 
provides limited information about network interfaces on the system 
(their names only).


The attached patch adds support for NetworkInterfaceType and 
GetPhysicalAddress() on Mac OS.


Oops, I've almost forgot about IPv6... and missed the added file 
MacOsNetworkInterfaceMarshal.


Please see the fixed patch instead.

--
Alex

Index: System.dll.sources
===
--- System.dll.sources	(revision 133967)
+++ System.dll.sources	(working copy)
@@ -761,6 +761,7 @@
 System.Net.NetworkInformation/IPv4InterfaceStatistics.cs
 System.Net.NetworkInformation/IPv6InterfaceProperties.cs
 System.Net.NetworkInformation/LinuxNetworkInterfaceMarshal.cs
+System.Net.NetworkInformation/MacOsNetworkInterfaceMarshal.cs
 System.Net.NetworkInformation/MulticastIPAddressInformationCollection.cs
 System.Net.NetworkInformation/MulticastIPAddressInformation.cs
 System.Net.NetworkInformation/NetBiosNodeType.cs
Index: System.Net.NetworkInformation/IPv4InterfaceStatistics.cs
===
--- System.Net.NetworkInformation/IPv4InterfaceStatistics.cs	(revision 133967)
+++ System.Net.NetworkInformation/IPv4InterfaceStatistics.cs	(working copy)
@@ -201,8 +201,65 @@
 return Read ("statistics/tx_packets");
 			}
 		}
+	}
 
+	// dummy class
+	class MacOsIPv4InterfaceStatistics : IPv4InterfaceStatistics
+	{
+		MacOsNetworkInterface macos;
 		
+		public MacOsIPv4InterfaceStatistics (MacOsNetworkInterface parent)
+		{
+			macos = parent;
+		}
+
+		public override long BytesReceived {
+			get { return 0; }
+		}
+
+		public override long BytesSent {
+			get { return 0; }
+		}
+
+		public override long IncomingPacketsDiscarded {
+			get { return 0; }
+		}
+
+		public override long IncomingPacketsWithErrors {
+			get { return 0; }
+		}
+
+		public override long IncomingUnknownProtocolPackets {
+			get { return 0; }
+		}
+
+		public override long NonUnicastPacketsReceived {
+			get { return 0; }
+		}
+
+		public override long NonUnicastPacketsSent {
+			get { return 0; }
+		}
+
+		public override long OutgoingPacketsDiscarded {
+			get { return 0; }
+		}
+
+		public override long OutgoingPacketsWithErrors {
+			get { return 0; }
+		}
+
+		public override long OutputQueueLength {
+			get { return 0; }
+		}
+
+		public override long UnicastPacketsReceived {
+			get { return 0; }
+		}
+
+		public override long UnicastPacketsSent {
+			get { return 0; }
+		}
 	}
 	
 }
Index: System.Net.NetworkInformation/MacOsNetworkInterfaceMarshal.cs
===
--- System.Net.NetworkInformation/MacOsNetworkInterfaceMarshal.cs	(revision 0)
+++ System.Net.NetworkInformation/MacOsNetworkInterfaceMarshal.cs	(revision 0)
@@ -0,0 +1,73 @@
+#if NET_2_0
+using System;
+using System.Runtime.InteropServices;
+
+namespace System.Net.NetworkInformation {
+	namespace MacOsStructs {
+		internal struct ifaddrs
+		{
+			public IntPtr  ifa_next;
+			public string  ifa_name;
+			public uintifa_flags;
+			public IntPtr  ifa_addr;
+			public IntPtr  ifa_netmask;
+			public IntPtr  ifa_dstaddr;
+			public IntPtr  ifa_data;
+		}
+
+		internal struct sockaddr
+		{
+			public byte  sa_len;
+			public byte  sa_family;
+		}
+
+		internal struct sockaddr_in
+		{
+			public byte   sin_len;
+			public byte   sin_family;
+			public ushort sin_port;
+			public uint   sin_addr;
+		}
+
+		internal struct in6_addr
+		{
+			[MarshalAs (UnmanagedType.ByValArray, SizeConst=16)]
+			public byte[] u6_addr8;
+		}
+
+		internal struct sockaddr_in6
+		{
+			public byte sin6_len;
+			public byte sin6_family;
+			public ushort   sin6_port;
+			public uint sin6_flowinfo;
+			public in6_addr sin6_addr;
+			public uint sin6_scope_id;
+		}
+
+		internal struct sockaddr_dl
+		{
+			public byte   sdl_len;
+			public byte   sdl_family;
+			public ushort sdl_index;
+			public byte   sdl_type;
+			public byte   sdl_nlen;
+			public byte   sdl_alen;
+			public byte   sdl_slen;
+
+			[MarshalAs (UnmanagedType.ByValArray, SizeConst=12)]
+			public byte[] sdl_data;
+		}
+
+	}
+
+	internal enum MacOsArpHardware {
+		ETHER = 0x6,
+		ATM = 0x25,
+		SLIP = 0x1c,
+		PPP = 0x17,
+		LOOPBACK = 0x18,
+		FDDI = 0xf
+	}
+}
+#endif
Index: System.Net.NetworkInformation/IPv4InterfaceProperties.cs
===
--- System.Net.NetworkInformation/IPv4InterfaceProperties.cs	(revision 133967)
+++ System.Net.NetworkInformation/IPv4InterfaceProperties.cs	(working copy)
@@ -46,17 +46,17 @@
 		public abstract bool UsesWins { get; }
 	}
 
-	sealed class LinuxIPv4InterfaceProperties : IPv4InterfaceProperties
+	abstract class UnixIPv4InterfaceProperties : IPv4InterfaceProperties
 	{
-		LinuxNetworkInterface iface;
+		protected UnixNetworkInterface iface;
 		
-		public LinuxIPv4Inte

[Mono-dev] [PATCH] Simple implementation of network interface properties for Mac OS X

[Alex Shulgin]

Hi,

In the current version System.Net.NetworkInformation.NetworkInterface 
provides limited information about network interfaces on the system 
(their names only).


The attached patch adds support for NetworkInterfaceType and 
GetPhysicalAddress() on Mac OS.


The outline of the changes is as follows:

- Used the same trick with uname as in MWF XplatUI to detect if running 
Mac OS.


- In several places I've added base classes like UnixNetworkInterface to 
derive Linux- and MacOs- implementation classes from them.  Where 
possible, common code moved to Unix- classes; in some places dummy 
methods are used to return default "don't know" values (0, false, "").


- Added new file MacOsNetworkInterfaceMarshal to define MacOs-specific 
(BSD) structs like sockaddr as they're slightly different from those 
used in Linux.


Comments are welcome! :)

--
Cheers,
Alex
Index: System.dll.sources
===
--- System.dll.sources	(revision 133967)
+++ System.dll.sources	(working copy)
@@ -761,6 +761,7 @@
 System.Net.NetworkInformation/IPv4InterfaceStatistics.cs
 System.Net.NetworkInformation/IPv6InterfaceProperties.cs
 System.Net.NetworkInformation/LinuxNetworkInterfaceMarshal.cs
+System.Net.NetworkInformation/MacOsNetworkInterfaceMarshal.cs
 System.Net.NetworkInformation/MulticastIPAddressInformationCollection.cs
 System.Net.NetworkInformation/MulticastIPAddressInformation.cs
 System.Net.NetworkInformation/NetBiosNodeType.cs
Index: System.Net.NetworkInformation/IPv4InterfaceStatistics.cs
===
--- System.Net.NetworkInformation/IPv4InterfaceStatistics.cs	(revision 133967)
+++ System.Net.NetworkInformation/IPv4InterfaceStatistics.cs	(working copy)
@@ -201,8 +201,65 @@
 return Read ("statistics/tx_packets");
 			}
 		}
+	}
 
+	// dummy class
+	class MacOsIPv4InterfaceStatistics : IPv4InterfaceStatistics
+	{
+		MacOsNetworkInterface macos;
 		
+		public MacOsIPv4InterfaceStatistics (MacOsNetworkInterface parent)
+		{
+			macos = parent;
+		}
+
+		public override long BytesReceived {
+			get { return 0; }
+		}
+
+		public override long BytesSent {
+			get { return 0; }
+		}
+
+		public override long IncomingPacketsDiscarded {
+			get { return 0; }
+		}
+
+		public override long IncomingPacketsWithErrors {
+			get { return 0; }
+		}
+
+		public override long IncomingUnknownProtocolPackets {
+			get { return 0; }
+		}
+
+		public override long NonUnicastPacketsReceived {
+			get { return 0; }
+		}
+
+		public override long NonUnicastPacketsSent {
+			get { return 0; }
+		}
+
+		public override long OutgoingPacketsDiscarded {
+			get { return 0; }
+		}
+
+		public override long OutgoingPacketsWithErrors {
+			get { return 0; }
+		}
+
+		public override long OutputQueueLength {
+			get { return 0; }
+		}
+
+		public override long UnicastPacketsReceived {
+			get { return 0; }
+		}
+
+		public override long UnicastPacketsSent {
+			get { return 0; }
+		}
 	}
 	
 }
Index: System.Net.NetworkInformation/IPv4InterfaceProperties.cs
===
--- System.Net.NetworkInformation/IPv4InterfaceProperties.cs	(revision 133967)
+++ System.Net.NetworkInformation/IPv4InterfaceProperties.cs	(working copy)
@@ -46,17 +46,17 @@
 		public abstract bool UsesWins { get; }
 	}
 
-	sealed class LinuxIPv4InterfaceProperties : IPv4InterfaceProperties
+	abstract class UnixIPv4InterfaceProperties : IPv4InterfaceProperties
 	{
-		LinuxNetworkInterface iface;
+		protected UnixNetworkInterface iface;
 		
-		public LinuxIPv4InterfaceProperties (LinuxNetworkInterface iface)
+		public UnixIPv4InterfaceProperties (UnixNetworkInterface iface)
 		{
 			this.iface = iface;
 		}
 		
 		public override int Index {
-			get { return LinuxNetworkInterface.IfNameToIndex (iface.Name); }
+			get { return UnixNetworkInterface.IfNameToIndex (iface.Name); }
 		}
 
 		// TODO: how to discover that?
@@ -74,6 +74,18 @@
 			get { return false; }
 		}
 	
+		public override bool UsesWins {
+			get { return false; }
+		}
+	}
+	
+	sealed class LinuxIPv4InterfaceProperties : UnixIPv4InterfaceProperties
+	{
+		public LinuxIPv4InterfaceProperties (LinuxNetworkInterface iface)
+			: base (iface)
+		{
+		}
+		
 		public override bool IsForwardingEnabled {
 			get {
 string iface_path = "/proc/sys/net/ipv4/conf/" + iface.Name + "/forwarding";
@@ -87,9 +99,10 @@
 return false;
 			}
 		}
+
 		public override int Mtu {
 			get {
-string iface_path = iface.IfacePath + "mtu";
+string iface_path = (iface as LinuxNetworkInterface).IfacePath + "mtu";
 int ret = 0;
 
 if (File.Exists (iface_path)) {
@@ -105,10 +118,24 @@
 		
 			}
 		}
-	
-		public override bool UsesWins {
+	}
+
+	sealed class MacOsIPv4InterfaceProperties : UnixIPv4InterfaceProperties
+	{
+		public MacOsIPv4InterfaceProperties (MacOsNetworkInterface iface)
+			: base (iface)
+		{
+		}
+
+		// dummy
+		public override bool Is

Re: [Mono-dev] [Mono-winforms-list] [BUMP] ToolStripDropDown + UserControl

[Alex Shulgin]

Alex Shulgin wrote:
> Alex Shulgin wrote:
>> Hi,
>>
>> I'm trying to add some custom control to ToolStripDropDown using 
>> ToolStripControlHost.
>>
>> This works fine with .NET, but with Mono (2.2) the control is always 
>> resized to 22 pixels tall...  Too bad I can't find a workaround for a 
>> few days now.
>>
>> Any help & suggestions are much appreciated. :)
> 
> If someone could tell how to create a popup window w/o using 
> ToolStripDropDown I'd be grateful.
> 
> Since it's exactly the thing I'm trying to accomplish--using 
> ToolStripDropDown is just the shortest way in .NET, but it seems to be 
> broken in Mono.

Hi All again!

I've done some more research on the issue.

While browsing through mono's System.Windows.Forms sources I've come 
across the following suspicious piece of code in ToolStripDropDown.OnLayout:

if (tsi is ToolStripSeparator)
 height = 7;
else
 height = 22;

http://preview.tinyurl.com/cdmrqu

This code is exactly what causes the described problem.  So I propose 
the following patch:

--- ToolStripDropDown.cs~   2009-02-14 01:55:14.0 +0200
+++ ToolStripDropDown.cs2009-03-03 17:57:10.0 +0200
@@ -579,19 +579,24 @@
{
// Find the widest menu item
int widest = 0;
+   bool haveStandardItems = false;

foreach (ToolStripItem tsi in this.Items) {
if (!tsi.Available)
continue;
+
+   if (!(tsi is ToolStripControlHost))
+   haveStandardItems = true;

tsi.SetPlacement (ToolStripItemPlacement.Main);

-   if (tsi.GetPreferredSize (Size.Empty).Width > 
widest)
-   widest = tsi.GetPreferredSize 
(Size.Empty).Width;
+   widest = Math.Max (widest, tsi.GetPreferredSize 
(Size.Empty).Width);
}
-   
+
int x = this.Padding.Left;
-   widest += 68 - this.Padding.Horizontal;
+   if (haveStandardItems)
+   widest += 68 - this.Padding.Horizontal;
+
int y = this.Padding.Top;

foreach (ToolStripItem tsi in this.Items) {
@@ -604,11 +609,13 @@

if (tsi is ToolStripSeparator)
height = 7;
+   else if (tsi is ToolStripControlHost)
+   height = tsi.GetPreferredSize 
(Size.Empty).Height;
else
height = 22;

tsi.SetBounds (new Rectangle (x, y, widest, 
height));
-   y += tsi.Height + tsi.Margin.Bottom;
+   y += /*tsi.Height*/ height + tsi.Margin.Bottom;
}

this.Size = new Size (widest + this.Padding.Horizontal, 
y + 
this.Padding.Bottom);// + 2);


--8<8<8<8<8<8<8<8<8<8<8<8<--

It uses a call to GetPreferredSize for ToolStripControlHost items 
instead of hard-coded value 22 (which is bizarre anyway).

The patch also preserves current behavior when the drop down menu is 
populated with 'standard' items like ToolStripButton, ToolStripLabel, 
etc. or a mix of standard and hosted custom items, so the things won't 
break.

If there's only custom items hosted via ToolStripControlHost the drop 
down now mimics 'correct' behavior of .NET ToolStripDropDown: the items 
are painted in full size and w/o decoration.

Btw, what's that another hard-coded value of 68?  Isn't this too much 
for a single method?.. :)

--
Thanks all,
Alex
PS: I really, really need some feedback on this issue...
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list