Re: [Mono-dev] Mono 3.2.8 incompatibility with .NET 4.0 on Windows 7-10

[Dan Liew]

Hi,

> I've also got a link to a downloadable .zip file containing the sources and 
> the nUnit package for easy compiling on Windows as well as Linux without 
> having to create your own project (done due to size restrictions on the 
> mailing list). nUnit 2.6.4 is present, so that it compiles out of the box on 
> both platforms (sorry, not sure how best to set up two platforms 
> simultaneously, but that's another topic). The nUnit test cases are in the 
> file Test.cs.

I just tried building your test project and running the test cases
under Mono 4.2.1, they pass.

> I'm looking on advice on how to work around the differences. I can't change
> the version of Mono I'm using (I'm restricted to Ubuntu 14.04.3 for the next
> three years).

You are unlikely to get much help when reporting bugs with such an old
version of Mono.

Although you say you are restricted to using Ubuntu 14.04 that doesn't
stop you from using a newer version of Mono.

Xamarin provide repositories containing newer builds of Mono which you can use.

http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives

You can always build from source too :)

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

Re: [Mono-dev] The impact of running dlls compiled with /platform:x86 on a x86_64 machine under mono

[Dan Liew]

On 6 November 2015 at 05:29, Rodrigo Kumpera  wrote:
> Mono ignores those settings and will run with the bitness it was compiled
> as.

Okay, by "it" I presume you are referring to the target Mono was
compiled for, not the target the application was compiled for.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] System.Diagnostics.Process behaves differently in and outside of a NUnit test case

[Dan Liew]

Hi Ludovic,

On 15 October 2015 at 12:47, Ludovic Henry  wrote:
> Hi Dan,
>
> As I am currently working on the Process class, I am getting a look at your
> bug.

Thanks for taking a look :)

>
> Does setting  StandardOutputEncoding = Console.OutputEncoding on the
> ProcessStartInfo passed to Start fixes your issue? This is the behaviour on
> .NET, so this is the behaviour that we are going to adopt (at least for bug
> compatibility).

For the version of mono I'm currently using (4.0.4) doing this doesn't work

```
StartInfo = new ProcessStartInfo(PathToSolverExecutable);
StartInfo.Arguments = solverArguments;
StartInfo.RedirectStandardInput = true; // Neccessary so we can send our query
StartInfo.RedirectStandardOutput = true; // Necessary so we can read the output
StartInfo.RedirectStandardError = true;
StartInfo.UseShellExecute = false; // C# docs say this is required

// This is a HACK
TheEncoding = new System.Text.UTF8Encoding(/*
encoderShouldEmitUTF8Identifier=*/ false);
StartInfo.StandardOutputEncoding = TheEncoding;
```

The standard input stream is still sending the UTF-8 BOM. But doing
this before creating the process
works.

```
Console.OutputEncoding = new System.Text.UTF8Encoding(/*
encoderShouldEmitUTF8Identifier=*/ false);
```

The only reason I knew to do this is because I looked at the
implementation of ``System.Diagnostics.Process`` on my system
and saw that this the encoding that is being used comes from
``Console.Out.Encoding`` and took a guess that if I modified
``Console.OutputEncoding`` the change "might" propagate to
``Console.Out.Encoding``. Here's the implementation code I
was looking at.

```
if (startInfo.RedirectStandardInput == true) {
MonoIO.Close (stdin_rd, out error);
process.input_stream = new StreamWriter (new MonoSyncFileStream
(stdin_wr, FileAccess.Write, true, 8192), Console.Out.Encoding);
process.input_stream.AutoFlush = true;
}
```

However I've noticed that the code in the master branch of mono is
different. At a glance it looks like it's using
``startInfo.StandardOutputEncoding``
if it's not null

```
if (startInfo.RedirectStandardOutput) {
MonoIO.Close (stdout_write, out error);
Encoding stdoutEncoding = startInfo.StandardOutputEncoding ??
Console.Out.Encoding;
process.output_stream = new StreamReader (new FileStream (new
SafeFileHandle (stdout_read, false), FileAccess.Read, 8192, false),
stdoutEncoding, true, 8192);
}
```

So it looks like a nicer workaround is now available (I've not tested
it though). It's a bit of a pain though as I can't rely on it in older
versions of mono which means I have to use my horrible hack anyway :(


Please note that the bug I filled about NUnit [1] has had a response.
It sounds like NUnit is deliberately changing the encoding
on standard output because they expect that it being redirected to a file.

[1] https://github.com/nunit/nunit/issues/881
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] System.Diagnostics.Process behaves differently in and outside of a NUnit test case

[Dan Liew]

Hi,

This is an issue that I was bitten by a while ago but I didn't post
here because I managed to work around it but it looks like something
inside mono changed between 3.12 and 4.0.4 which my broke my
workaround.

The issue basically is I observed my code failing when called from an
NUnit test but when run from an executable it would work fine. The
code in question [1] calls out to an external process using
``System.Diagnostics.Process`` where the standard input is redirected.
When running from an NUnit test a UTF-8 BOM gets sent to the process's
standard input and when running from an executable the UTF-8 BOM does
not get sent.

I looked at this again and I've noticed two things

* In System.Diagnostics.Process.Start_noshell() the encoding for the
writable end of the pipe connected to the child process's standard
input is taken from ``Console.Out.Encoding``. Is this really a good
idea? Depending on this global value seems like a bad idea and could
introduce weird race conditions if the Console.Out encoding is changed
in some way (e.g. ``Console.OutputEncoding = new
System.Text.UTF8Encoding(false);`` seems to do this and this the new
workaround I ended up using)

* When running in an executable the value of
``Console.Out.Encoding.emitUTF8Identifier`` is false but when running
in an NUnit test the value of
Console.Out.Encoding.emitUTF8Identifier`` is true!
I'm not sure if this is Mono's or NUnit's fault but this seems very wrong to me.

I've filled a bug at [2] and [3] but thought I'd post about it here
too as this issue seems partially tied to some of mono's internal
implementation details.

[1] https://bugzilla.xamarin.com/attachment.cgi?id=13247
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=21374
[3] https://github.com/nunit/nunit/issues/881

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

Re: [Mono-dev] Profiling / Memory Management tools

[Dan Liew]

On 31 May 2015 at 17:35, Greg Young gregoryyou...@gmail.com wrote:
 What tools are people using with mono? I have tried as an example
 using valgrind to verify the stuff I am working on is reasonable but
 the listings of problems that come out are massive.

Checking the memory usage via valgrind will be pretty useless to you
unless you know the mono internals. If you do want to continue down
that route look at [1].

You're more likely to be interested in memory use at the level of your
C#/F# code. To do this I've used mono's built-in memory profiling [2],
e.g.

$ mono --profile=log:heapshot my_program.exe

You can specify how frequently shots of the heap are taken. You can
view the result using mprof or heapshot [3].

[1] http://www.mono-project.com/docs/debug+profile/debug/#using-valgrind-on-mono
[2] 
http://www.mono-project.com/docs/debug+profile/profile/profiler/#profiler-option-documentation
[3] https://github.com/mono/heap-shot
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building from Source Fails with mcs: Command not found (Mono-devel-list Digest, Vol 121, Issue 19) (Mono-devel-list Digest, Vol 121, Issue 20)

[Dan Liew]

On 22 May 2015 at 14:21, Cyd Haselton chasel...@gmail.com wrote:


 On May 22, 2015 7:34:16 AM CDT, Jo Shields direct...@apebox.org wrote:


On 22/05/15 01:16, cyd wrote:
 Let me back up a few steps before I start troublehooting this.

 Does the monolite build of mono 4.0 support ARM...specifically ARMv7?
 If
 so, are there any modifications I need to make before running 'make
 make
 install?'

Monolite is CPU-agnostic. It's just bytecode. Mono 4 supports ARMv7, so
the question is what instructions are triggering SIGILL
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

 Running 'strace -v -o mono.log make check', then 'cat mono.log | grep -B 12 
 SIGILL' yields:

 mprotect(0x40085000, 4096, PROT_READ)   = 0
 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
 gettid()= 10243
 syscall_983045(0x40086f24, 0xffb8, 0, 0x40086f24, 0x40087154, 0, 
 0xbeaec0d0, 0xf0005, 0x4008715c, 0xbe2ed000, 0, 0, 0, 0xbeaec070, 0x4007e254, 
 0x4007eaa4, 0x6010, 0x40086f24, 0, 0, 0xc764, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 0, 0) = 0
 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 
 0x40089000madvise(0x40089000, 8192, 0xc /* MADV_??? */) = -1 EINVAL (Invalid 
 argument)
 sigaltstack({ss_sp=0x40089000, ss_flags=0, ss_size=8192}, NULL) = 0
 sigaction(SIGABRT, {0x40076a71, [], SA_STACK|SA_RESTART|SA_SIGINFO}, NULL, 
 0x1dd9028) = 0
 sigaction(SIGBUS, {0x40076a71, [], SA_STACK|SA_RESTART|SA_SIGINFO}, NULL, 
 0x1dd9028) = 0
 sigaction(SIGFPE, {0x40076a71, [], SA_STACK|SA_RESTART|SA_SIGINFO}, NULL, 
 0x1dd9028) = 0
 sigaction(SIGILL, {0x40076a71, [], SA_STACK|SA_RESTART|SA_SIGINFO}, NULL, 
 0x1dd9028) = 0

 I have zero experience reading straces but if I had to guess it looks like a 
 function is making an invalid memory call.

Isn't the sigaction there setting up the signal handler for SIGILL? If
so this is probably the wrong part to be looking at. I'm slightly
confused by the sigaction written here because it's taking four
arguments but sigaction only takes three (I'm not great at reading the
output of strace either).

Another way to debug this is run the program under gdb and make sure
you set it up to intercept SIGILL. When gdb catches SIGILL you can
walk through the stack and also examine the assembly to see if
anything looks suspect to you.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list