I'd certainly have to see *some* kind of reproducible system before
considering it likely to be a CLR bug.

Rather than create a new test program from scratch, have you tried
taking a new copy of your full application, and ripping bits out of it
(retesting each time) until you've either got a small program
demonstrating the problem or you've found the bug?

Sounds very interesting.  I'd like to see a simple repro as well before I
would consider this a bug in the CLR.  However, think about this:  a
hashtable has a default size and is a memory hungry object.  Given the way
the CLR constructs this class it may get mapped in memory to the same
place.   In the case where it does get mapped into the same place within
memory and there is no initialization of the object you may wind up with
the values were in there from the previous run.  Of course this is purely
speculative and highly unlikely.  

A more probable explination is that something in your code is modifying
this object.  If it were a problem with the CLR you'd probably see this in
multiple applications.

Thanks!  Robert Gruen
Microsoft, VB.NET

This posting is provided "AS IS", with no warranties, and confers no rights.
--------------------
#Thread-Topic: Instance members change after it's constructor returns
#thread-index: AcQxNoFDdY/H2xFBQYKEgUSPwX0PeA==
#X-WN-Post: microsoft.public.dotnet.framework.clr
#From: "=?Utf-8?B?a292ZXJ0b24=?=" <anonymous@discussions.microsoft.com>
#Subject: Instance members change after it's constructor returns
#Date: Mon, 3 May 2004 10:46:04 -0700
#Lines: 17
#Message-ID: <C1B825BC-6756-4845-A023-100B982E26E0@microsoft.com>
#MIME-Version: 1.0
#Content-Type: text/plain;
#    charset="Utf-8"
#Content-Transfer-Encoding: 7bit
#X-Newsreader: Microsoft CDO for Windows 2000
#Content-Class: urn:content-classes:message
#Importance: normal
#Priority: normal
#X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
#Newsgroups: microsoft.public.dotnet.framework.clr
#Path: cpmsftngxa10.phx.gbl
#Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:10470
#NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
#X-Tomcat-NG: microsoft.public.dotnet.framework.clr
#
#Here's an example, this is the constructor for an object (plus a member it
initializes):

public class MyObj {
//etc.
private Hashtable idlist;
public MyObj (string localityName) {
// etc.
idlist = new Hashtable();
}
//etc
}

Under the debugger, as I step into this constructor and create a new
Hashtable, it is empty, which is perfectly rational. As I step OUT of the
constructor, I see in the caller that the constructed object has a
Hashtable with hundreds of entries in it. The data inside seems like
perfectly reasonable data, the kind that would have probably ended up there
if the code that loads the table were ever to run -- but it DIDN'T run, and
yet here's all this data. This only happens in our larger project, it does
not happen in tiny test projects that I build to try to replicate the
problem.

The part that must be causing the problem is that we have an abstract
loader using reflection to automatically load instances of any object. Our
constructors are trivial, just initialize the instances so that the loader
can load them up. I have breakpoints in the loader and in the reader that
the loader would eventually call, but I never reach those breakpoints. I
also have a different project without the loading classes (where I read in
the data "by hand" so to speak) that does not have this problem.

Two of my colleagues have confirmed that they see this too. Help? I look
through the ASM code but it seems pretty unremarkable too. At this point I
believe it's a bug in the .NET CLR (or perhaps a dbg-only) but since it's a
black box I don't know how to confirm this.
#

constructor, I see in the caller that the constructed object has a Hashtable
with hundreds of entries in it. The data inside seems like perfectly
reasonable data, the kind that would have probably ended up there if the
code that loads the table were ever to run -- but it DIDN'T run, and yet
here's all this data. This only happens in our larger project, it does not
happen in tiny test projects that I build to try to replicate the problem.

constructors are trivial, just initialize the instances so that the loader
can load them up. I have breakpoints in the loader and in the reader that
the loader would eventually call, but I never reach those breakpoints. I
also have a different project without the loading classes (where I read in
the data "by hand" so to speak) that does not have this problem.

believe it's a bug in the .NET CLR (or perhaps a dbg-only) but since it's a
black box I don't know how to confirm this.

Did you try to set a breakpoint in the method that fills the hashtable?

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu  || http://www.deutronium.tk

Do you have a property in the class which would fill the hashtable? The
debugger may well be evaluating the property, if the object appears in a
watch window.

Property 'gets' with side-effects don't always work nicely when you're using
a debugger.

Stu

constructor, I see in the caller that the constructed object has a Hashtable
with hundreds of entries in it. The data inside seems like perfectly
reasonable data, the kind that would have probably ended up there if the
code that loads the table were ever to run -- but it DIDN'T run, and yet
here's all this data. This only happens in our larger project, it does not
happen in tiny test projects that I build to try to replicate the problem.

constructors are trivial, just initialize the instances so that the loader
can load them up. I have breakpoints in the loader and in the reader that
the loader would eventually call, but I never reach those breakpoints. I
also have a different project without the loading classes (where I read in
the data "by hand" so to speak) that does not have this problem.

believe it's a bug in the .NET CLR (or perhaps a dbg-only) but since it's a
black box I don't know how to confirm this.