[Mono-dev] Recent commits cause problems with thread test cases

2015-10-09 Thread Bill Seurer 
There are a couple of recent commits which cause problems for some 
thread-related things in mono/tests.  At least they do on power.  I did 
a refresh (fetch/rebase) from mono/master just before I tried things a 
few minutes ago so no later commits fixed the problems.


The commits causing grief appear to be these:

commit 7aae649458bceb4375b74f078c4f24ddd4a486f5
Merge: e6ad2dc e5e97ea
Author: Rodrigo Kumpera 
Date: Tue Oct 6 10:40:47 2015 -0400

Merge pull request #2060 from ludovic-henry/socket-rework-async

[socket] Complete refactor of Begin/End and Async

commit e6ad2dc73b415e091c80a9912c66e86af1e7a761
Merge: 0056f1f 388b958
Author: Rodrigo Kumpera 
Date: Tue Oct 6 10:19:19 2015 -0400

Merge pull request #2110 from ludovic-henry/threadpool-exit-worker

[threadpool-ms] Exit worker thread after 5 to 60 seconds


Things worked fine with the commit previous to the above two which is 
this one:


commit 11096e3733b808a8bbfce262c256ec89887cac89
Author: Ludovic Henry 
Date: Tue Sep 15 11:21:55 2015 +0100


One symptom is tests that hang.  threadpool.cs is one example of that.

The other symptom is this failure:

seurer@genoa:~/mono-git/mono-checkin/mono/tests$ make runtest-managed-serial
Testing bug-2907.exe... passed.
Testing array-init.exe... passed.
Testing arraylist.exe...
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance 
of an object
  at TestRunner+c__AnonStorey0.<>m__1 (System.Object sender, 
System.Diagnostics.DataReceivedEventArgs e) [0x00066] in 
/home/seurer/mono-git/mono-checkin/mono/tests/test-runner.cs:286
  at System.Diagnostics.Process.OnOutputDataReceived (System.String 
str) [0xd] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1294 

  at (wrapper remoting-invoke-with-check) 
System.Diagnostics.Process:OnOutputDataReceived (string)
  at System.Diagnostics.Process+ProcessAsyncReader.AddInput () 
[0x00058] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1354 

  at System.Diagnostics.Process+ProcessAsyncReader.m__0 
(System.IOAsyncResult _) [0x0] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1335 

  at 
System.IOSelectorJob.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () 
[0x0] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System/IOSelector.cs:143 

  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00096] in 
/home/seurer/mono-git/mono-checkin/external/referencesource/mscorlib/system/threading/threadpool.cs:859 

  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () 
[0x0] in 
/home/seurer/mono-git/mono-checkin/external/referencesource/mscorlib/system/threading/threadpool.cs:1196 



Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance 
of an object
  at TestRunner+c__AnonStorey0.<>m__2 (System.Object sender, 
System.Diagnostics.DataReceivedEventArgs e) [0x00066] in 
/home/seurer/mono-git/mono-checkin/mono/tests/test-runner.cs:307
  at System.Diagnostics.Process.OnErrorDataReceived (System.String str) 
[0xd] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1301 

  at (wrapper remoting-invoke-with-check) 
System.Diagnostics.Process:OnErrorDataReceived (string)
  at System.Diagnostics.Process+ProcessAsyncReader.AddInput () 
[0x00069] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1356 

  at System.Diagnostics.Process+ProcessAsyncReader.m__0 
(System.IOAsyncResult _) [0x0] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System.Diagnostics/Process.cs:1335 

  at 
System.IOSelectorJob.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () 
[0x0] in 
/home/seurer/mono-git/mono-checkin/mcs/class/System/System/IOSelector.cs:143 

  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00096] in 
/home/seurer/mono-git/mono-checkin/external/referencesource/mscorlib/system/threading/threadpool.cs:859 

  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () 
[0x0] in 
/home/seurer/mono-git/mono-checkin/external/referencesource/mscorlib/system/threading/threadpool.cs:1196 


make: *** [runtest-managed-serial] Error 255

--

-Bill Seurer

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

Re: [Mono-dev] System.DirectoryServices.DirectoryEntry.ObjectSecurity property

2015-10-09 Thread Numpsy 
Right, first change in :-)

Are we looking at 4.3.0 to get this sort of addition into a release build,
or is there still a possibility of changes getting into 4.2.(0/1)? I'm
currently doing OSX dev with a local 64bit build of 4.2.1 and I can patch
that if i need to, but it would be useful to know for reference.

Thanks,
Richard Webb



--
View this message in context: 
http://mono.1490590.n4.nabble.com/System-DirectoryServices-DirectoryEntry-ObjectSecurity-property-tp4666718p4666734.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] System.Diagnostics.Process behaves differently in and outside of a NUnit test case

2015-10-09 Thread 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