Thread vanishes during Convert.ChangeType() call

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

If the following snippet of C# code is executed in a loop for a few 100,000
times – the CLR finally gives up and kills the thread:

try
{
// This will throw NullReferenceException
Convert.ChangeType( null, typeof(double) );
}
catch (Exception ex)
{
m_ExceptionCount++;
}

Some additional info:
- Number of exceptions to be thrown before the thread dies is not consistent
– in my tests it ranged from 100,000 to 2,000,000. Usually takes a few
minutes in specially built program for the thread to vanish. But in real-life
application it took a couple of days for the problem to show up – very nasty!
- In order for the problem to happen the processor needs to be loaded with
some background task. I had a second thread crunching some numbers to keep
the processor busy.
- When the thread vanishes there no exceptions caught by any try-catch
statement on the call stack. But current application domain raises an
UnhandledException event that can be caught when it is too late to save the
thread.
- The problem seems to be specific to 1.1 version of the framework – it does
not happen on 2.0. In fact, Convert.ChangeType does not throw
NullReferenceException on the later version.

Could someone confirm that this is a bug?
Is there are any other known cases when for this problem exists?

I have a simple Visual Studio 2003 project that consistently reproduces the
problem. If you would like to see the problem and do not feel like spending
time to build your own or have problems in reproducing it please contact me
directly – I will send you the code.

Thank you,

Alex.
 
I Created a windows from project, and test following code:

int m_ExceptionCount;

m_ExceptionCount=0;

for (int i=0;i<1000000;i++)
try
{
// This will throw NullReferenceException
Convert.ChangeType( null, typeof(double) );
}
catch (Exception ex)
{
m_ExceptionCount++;

}


But I didn't see the problem. I have .NET framework 1.1 sp1 installed. Is
this different with you?

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Thank you for trying to reproduce the problem, Luke.

There are a few things that you might need to provide to make the problem
exposing itself:

1. Increese number of itterations: 1,000,000 might be not enough. Sometimes
it takes twice than that.

2. The most important part is to keep the processor busy with some other
task on background (I had another thread in the same process doing that).
This is important.

3. I am not sure if this is important but I also gave the both threads a
chance to sleep after certain number if iteration (because my “real-lifeâ€
application was doing that and I wanted to simulate exact behavior). The
following pseudo-code shows my exact timing and number of iterations:

“Vanishing†thread:
WHILE got exit signal
{
SLEEP 333 ms
DO 30,000 times
{
CALL Convert.ChangeType() to THROW
CATCH
}
}

“Background threadâ€:
WHILE got exit signal
{
SLEEP 555 ms
DO 400,000 times
{
String str = “123â€;
str.Split();
}
}

I tested this on Windows 2003 Server and Windows XP with different hardware.
I also tried it on a single- and multi-processors machines. The thread always
vanishes, the only thing is different is number of iteration (which is
inconsistent anyway) before it happens.

If you do not mind sending me you contact address at:
alex dot kravchenko _at_ pwrm dot com
I will provide you with all the code of simulating project that always kills
the thread.


Thank you,

Alex.
 
And...
one more IMPORTANT thing I forgot to mention:

4. The program must run with NO DEBUGGER ATTACHED. You can still attach the
debugger after the thread stops to see the post-mortal state. The condition
can be detected either by observing CPU Usage History or by catching
UnhandleException event sent by the current AppliactionDomain.

Alex.
 
Sorry Luke, I forgot to answer you question.

I was running the program against the same version of .NET framework:
1.1.4322 SP1

Alex.
 
Hello,

Thank you for the information. Can you send me a reproducable sample
project. To get my actual email, please remove "online" from my email
address.

Thanks,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Hello,

Thank you for the message. I have recieved your sample project and
reproduced the problem on my side. I found you run two threads in the
application, on e is named as "backgroud" thread. What is the thread for?
just make the system busy? I tried to remove this thread and problem seems
to disappear (at least it are running more than one hour without
exception).

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Luke,

That is correct, keeping the system busy seems to be a required condition
for the problem to appear. I was running system for a few days without
background task and all NullReferenceExceptions thrown from
Covert.ChangeType() were caught.

Thank you,
 
In your sample project, you used another thread to make the system busy.
Can we change it to other process? For example, run another application
which require most of CPU time, and jsut leave one thread in the original
project, can this reproduce the problem? This may help us make if this is a
multiple threading issue, or system resource (CPU) issue.

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
The other, background thread has to be in the same process for the problem to
happen.
I ran the test using two processes, one with one tread calling
Convert.ChangeType() the other with one thread keeping the CPU busy. Although
aggregated CPU load appeared to be the same as with two-thread test, the
problem has not occurred.

Alex.
 
So I suspect this should be a multiple threading problem. Currelty, I
didn't see a similar bug reported.

In you actual project, was the problem caused by:

Convert.ChangeType( null, typeof(double) );

Or something else?

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Yes, it does look like a multi-threading problem specific to
Convert.ChangeType() implementation on .NET 1.1.

I tried a few other ways to throw the same type of exception under similar
conditions - the problem never happened, only during Covert.ChangeType()
execution.
The target type does not need to be "double" though, the problem occurs
during conversions of null value to other types as well.

Alex.
 
In an actual project, we may get around this problem easily by this way:

First verify an object is null, if not, convert it with:

Convert.ChangeType( null, typeof(double) );

Can this solution work for you?

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Yes, checking for null values is the way to avoid the problem in this
particular case.

But I would feel much safer if this behavior was a confirmed platform bug
and it was specific only to Convert.ChangeType() call. It is very dangereous
when a thread dies with exceptions slipping through all cach statements.

Alex.
 
To comfirm this is bug, we may need more details steps, for example, perfom
a memory dump when the exception was thrown. I suggest you may submit a
support incident to our PSS about this. They amy assist you to confrm this:

http://msdn.microsoft.com/subscriptions/

Regards,

Luke Zhang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Back
Top