nunit-core team mailing list archive

[Sune Foldager <sune.foldager@xxxxxxxxx>]

Public bug reported:

The problem is related to accessing AppDomain evidence in the child
(test) domain. This causes a hidden cross-domain call back to the main
domain, carrying along any call context data that can, then, not
deserialize in the main domain. The problem is somewhat similar, but not
identical or directly related, to another bug (#1084181)

The problem is not 100% solvable, but it's magnified by the fact that
certain seemingly benign system calls, such as XmlSchema.Read, access
the configuration system behind the scenes, which, when it's the first
access, accesses AppDomain evidence.

This problem has gotten worse in NUnit 2.6.2, as demonstrated below. I
have been experimenting a bit, and discovered an easy, albeit slightly
weird fix. The following test will always fail in NUnit 2.6.2, unless
another test which accessed the configuration system has run earlier in
the same run:

  [Test]
  public void XmlSchemaReadWithCallContext()
  {
    CallContext.SetData("mykey", new Data());
    XmlSchema.Read(new StringReader(@"<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
  }

where "Data" is any serializable class implementing
ILogicalThreadAffinative (it can be empty).

A solution is to make sure NUnit itself accesses the configuration
system in the test domain, before running any tests. This activates some
caching which prevents the evidence access from happening. A simple line
like this will suffice:

  System.Configuration.ConfigurationManager.GetSection("dummy");

to be executed in the test domain, before anything is placed in the call
context.

Attached is a file containing some relevant tests. NUnit 2.5.10 fails #3
(can't be helped, I think), 2.6.2 fails #1 as well (can be helped by the
above line). If run through ReSharper, both NUnits fail #2 as well,
which is related to the way evidence is passed to the test domain: if
the domain is created with evidence = null, #2 will fail, but not if
created with AppDomain.CurrentDomain.Evidence.

Note that tests must be run one at a time, with realods in-between to
get accurate results.

** Affects: nunitv2
     Importance: Undecided
         Status: New

** Attachment added: "Tests to exhibit cross-domain problems."
   https://bugs.launchpad.net/bugs/1167805/+attachment/3640054/+files/DomainTests.cs

** Description changed:

  The problem is related to accessing AppDomain evidence in the child
  (test) domain. This causes a hidden cross-domain call back to the main
  domain, carrying along any call context data that can, then, not
  deserialize in the main domain. The problem is similar, but not
  identical or directly realted, to another bug (#1084181)
  
  The problem is not 100% solvable, but it's magnified by the fact that
  certain seemingly benign system calls, such as XmlSchema.Read, access
  the configuration system behind the scenes, which, when it's the first
  access, accesses AppDomain evidence.
  
  This problem has gotten worse in NUnit 2.6.2, as demonstrated below. I
- have been experimenting a bit, and discovered an easy, albeit it
- slightly weird fix. The following test will always fail in NUnit 2.6.2,
- unless another test which accessed the configuration system has run
- earlier in the same run:
+ have been experimenting a bit, and discovered an easy, albeit slightly
+ weird fix. The following test will always fail in NUnit 2.6.2, unless
+ another test which accessed the configuration system has run earlier in
+ the same run:
  
-   [Test]
-   public void XmlSchemaReadWithCallContext()
-   {
-     CallContext.SetData("mykey", new Data());
-     XmlSchema.Read(new StringReader(@"<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
-   }
+   [Test]
+   public void XmlSchemaReadWithCallContext()
+   {
+     CallContext.SetData("mykey", new Data());
+     XmlSchema.Read(new StringReader(@"<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
+   }
  
  where "Data" is any serializable class implementing
  ILogicalThreadAffinative (it can be empty).
  
  A solution is to make sure NUnit itself accesses the configuration
  system in the test domain, before running any tests. This activates some
  caching which prevents the evidence access from happening. A simple line
  like this will suffice:
  
-   System.Configuration.ConfigurationManager.GetSection("dummy");
+   System.Configuration.ConfigurationManager.GetSection("dummy");
  
  to be executed in the test domain, before anything is placed in the call
  context.
  
  Attached is a file containing some relevant tests. NUnit 2.5.10 fails #3
  (can't be helped, I think), 2.6.2 fails #1 as well (can be helped by the
  above line). If run through ReSharper, both NUnits fail #2 as well,
  which is related to the way evidence is passed to the test domain: if
  the domain is created with evidence = null, #2 will fail, but not if
  created with AppDomain.CurrentDomain.Evidence.
  
  Note that tests must be run one at a time, with realods in-between to
  get accurate results.

** Description changed:

  The problem is related to accessing AppDomain evidence in the child
  (test) domain. This causes a hidden cross-domain call back to the main
  domain, carrying along any call context data that can, then, not
- deserialize in the main domain. The problem is similar, but not
- identical or directly realted, to another bug (#1084181)
+ deserialize in the main domain. The problem is somewhat similar, but not
+ identical or directly related, to another bug (#1084181)
  
  The problem is not 100% solvable, but it's magnified by the fact that
  certain seemingly benign system calls, such as XmlSchema.Read, access
  the configuration system behind the scenes, which, when it's the first
  access, accesses AppDomain evidence.
  
  This problem has gotten worse in NUnit 2.6.2, as demonstrated below. I
  have been experimenting a bit, and discovered an easy, albeit slightly
  weird fix. The following test will always fail in NUnit 2.6.2, unless
  another test which accessed the configuration system has run earlier in
  the same run:
  
    [Test]
    public void XmlSchemaReadWithCallContext()
    {
      CallContext.SetData("mykey", new Data());
      XmlSchema.Read(new StringReader(@"<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
    }
  
  where "Data" is any serializable class implementing
  ILogicalThreadAffinative (it can be empty).
  
  A solution is to make sure NUnit itself accesses the configuration
  system in the test domain, before running any tests. This activates some
  caching which prevents the evidence access from happening. A simple line
  like this will suffice:
  
    System.Configuration.ConfigurationManager.GetSection("dummy");
  
  to be executed in the test domain, before anything is placed in the call
  context.
  
  Attached is a file containing some relevant tests. NUnit 2.5.10 fails #3
  (can't be helped, I think), 2.6.2 fails #1 as well (can be helped by the
  above line). If run through ReSharper, both NUnits fail #2 as well,
  which is related to the way evidence is passed to the test domain: if
  the domain is created with evidence = null, #2 will fail, but not if
  created with AppDomain.CurrentDomain.Evidence.
  
  Note that tests must be run one at a time, with realods in-between to
  get accurate results.

-- 
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/1167805

Title:
  cross-domain problems with XmlSchema and call context

Status in NUnit V2 Test Framework:
  New

Bug description:
  The problem is related to accessing AppDomain evidence in the child
  (test) domain. This causes a hidden cross-domain call back to the main
  domain, carrying along any call context data that can, then, not
  deserialize in the main domain. The problem is somewhat similar, but
  not identical or directly related, to another bug (#1084181)

  The problem is not 100% solvable, but it's magnified by the fact that
  certain seemingly benign system calls, such as XmlSchema.Read, access
  the configuration system behind the scenes, which, when it's the first
  access, accesses AppDomain evidence.

  This problem has gotten worse in NUnit 2.6.2, as demonstrated below. I
  have been experimenting a bit, and discovered an easy, albeit slightly
  weird fix. The following test will always fail in NUnit 2.6.2, unless
  another test which accessed the configuration system has run earlier
  in the same run:

    [Test]
    public void XmlSchemaReadWithCallContext()
    {
      CallContext.SetData("mykey", new Data());
      XmlSchema.Read(new StringReader(@"<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
    }

  where "Data" is any serializable class implementing
  ILogicalThreadAffinative (it can be empty).

  A solution is to make sure NUnit itself accesses the configuration
  system in the test domain, before running any tests. This activates
  some caching which prevents the evidence access from happening. A
  simple line like this will suffice:

    System.Configuration.ConfigurationManager.GetSection("dummy");

  to be executed in the test domain, before anything is placed in the
  call context.

  Attached is a file containing some relevant tests. NUnit 2.5.10 fails
  #3 (can't be helped, I think), 2.6.2 fails #1 as well (can be helped
  by the above line). If run through ReSharper, both NUnits fail #2 as
  well, which is related to the way evidence is passed to the test
  domain: if the domain is created with evidence = null, #2 will fail,
  but not if created with AppDomain.CurrentDomain.Evidence.

  Note that tests must be run one at a time, with realods in-between to
  get accurate results.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nunitv2/+bug/1167805/+subscriptions