Re: Problem with exceptions
- From: "Bryan Phillips" <bphillips@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 13 May 2007 00:33:21 +0000
What happens when you run a debug build without a debugger attached? If the same problem occurs, it is not a problem the build. It would likely be a race condition caused by your code, the .Net Framework or both that is alleviated when the debugger is attached.
--
Bryan Phillips
MCT, MCSD, MCDBA, MCSE
Blog: http://bphillips76.spaces.live.com
Web Site: http://www.composablesystems.net
"Andrew McNab" <AndrewMcNab@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:C4AB651D-C095-4F80-9C0D-EAE55F981D55@xxxxxxxxxxxxx:
I have a program that's running 6 threads + client tcp socket threads. When I
execute it in the development environment with vshost as the shell, all runs
fine. All threads are exited properly etc.
When I run the executable outside of the vhost shell, an exception in my
code occurs 100% of the time. It's a release build so I'm unable to find
where it is exactly. The exception is a saffe handle exception which doens't
narrow it down at all.
In the output window, all threads are exiting with 0x00 and no exceptions
are thrown in the vhost shell. I'm pretty new to debugging tools as I used to
do things the old fashioned way but it doesn't work so well with multithread
applications. I was wondering if there were configuration options that
ignored or supressed certain exceptions and if I could modify it. I saw there
were options to break on exceptions.
I have narrowed it down to System.IO.Ports because the exception relates to
trying to use resources that are avaliable. In my best efforts to ensure that
no threads are trying to send or recieve on the serial port before
SerialPort.Close() is called, the exceptions is still thrown.
I also noticed that since I have been doing release builds that the code
doesn't behave the same way as the debug. In particular, I'm having problems
with public variables not being set or correctly read when they are assigned
values within classes or threads. Example below:
bool done_thread=false, stuff=false;
void MyThread(){
while(!stuff){
//do stuff
}
//cleanup
done_thread=true;
}
void killthread(){
stuff=true;
while(!done_thread); <------ hangs here
//abort thread
}
I've also tried using try/catch with ThreadAbortException to execute the
clean up code but i'm having problems with threads that use Thread.Sleep().
If Thread.Abort() is called while the thread is asleep, the thread hangs and
never reaches the while conditional and the entire app halts waiting for the
sleep to end. I understand from the documentation Thread.Abort() is much
similar to Thread.Interrupt() in terms of breaking sleep but also attempts to
dispose of the thread.
All of these behaviors arose when I decided to compile release. The code is
identical. Any starters or documentation links that explain differences
between debug and release builds would be fantastic. It's my naaive
understanding that the only difference between debug and release is that the
executables for debug compilations load symbols and entry points of code so
it can be debugged. I have a suspicion that debug compliations might also
have a larger tolerance for program errors which are strictly addressed by
the OS when they occur in release builds.
I'm using .Net 2.0 framework and programming in C#. Thanks :o)
.
- References:
- Problem with exceptions
- From: Andrew McNab
- Problem with exceptions
- Prev by Date: Re: On right click of solution,its requested(debug) to restart VS
- Next by Date: Re: Edit/Continue with anonymous methods
- Previous by thread: Problem with exceptions
- Next by thread: Visualizer for custom type?
- Index(es):
Loading