Detach Application.ThreadException Event, really?

  • Thread starter Thread starter Buddhist.CHinA
  • Start date Start date
B

Buddhist.CHinA

I read MSDN that described "Because this is a static event, you must
detach your event handlers when your application is disposed, or
memory leaks will result". But I didn't find out any exsited code
following this rule, or even mentioned about the detach.

Is it true? If yes, where to detach this static event?

Thanks.
 
I read MSDN that described "Because this is a static event, you must
detach your event handlers when your application is disposed, or
memory leaks will result". But I didn't find out any exsited code
following this rule, or even mentioned about the detach.

Is it true? If yes, where to detach this static event?

Thanks.
Click to expand...

Dear Buddhist,

I don't know any necessary special handling for static events.

Anyhow, if you'd like, you could unsubscribe from the ThreadException
in the ApplicationExit or ThreadExit event handlers, though I don't
think it's necessary.

Can you post a link to a site that mentions the issue?

Hope this helps,
Moty
 
Dear Buddhist,

I don't know any necessary special handling for static events.

Anyhow, if you'd like, you could unsubscribe from the ThreadException
in the ApplicationExit or ThreadExit event handlers, though I don't
think it's necessary.

Can you post a link to a site that mentions the issue?

Hope this helps,
Moty
Click to expand...

Thanks for your reply.

Please refer to:
http://msdn2.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx

You could find that message on the middle of the page.
 
Thanks for your reply.

Please refer to:http://msdn2.microsoft.com/en-us/library/system.windows.forms.applica...

You could find that message on the middle of the page.
Click to expand...

Dear Buddhist,

Now that I think of it, it surely needs to be unsubscribed since
static events survive GC collections.

Think about it: Static events has a collection of references. There is
not way to the GC to know that instance has no references to it since
there is not destruction of finalization method for the static event
container to release these references for you.

It's a memory leak just like referencing a child object in a root
object...

Hope it helps, and sorry for the late recall =)

Moty
 
Now that I think of it, it surely needs to be unsubscribed since
static events survive GC collections.

Think about it: Static events has a collection of references. There is
not way to the GC to know that instance has no references to it since
there is not destruction of finalization method for the static event
container to release these references for you.

It's a memory leak just like referencing a child object in a root
object...
Click to expand...

Your logic is sound, but I don't think it answers the question. Think
about this; the AppDomain is being torn down, and the process itself
will terminate. After all that occurs, is there still really anything
left to garbage collect?

I don't know the answer myself, but it seems that in the managed world
these things will get cleaned up automatically, assuming no unmanaged
resources are held by a managed object.
 
Your logic is sound, but I don't think it answers the question. Think
about this; the AppDomain is being torn down, and the process itself
will terminate. After all that occurs, is there still really anything
left to garbage collect?

I don't know the answer myself, but it seems that in the managed world
these things will get cleaned up automatically, assuming no unmanaged
resources are held by a managed object.
Click to expand...

Hi,

The memory leak is through the life cycle of your application.

After the application terminates, the memory space is reused by the OS
(It's the OS responsibility to manage the memory spaces).

But, there are services which in many ways will rarely terminate. In
these cases, static events GC is important especially if you use more
than one AppDomain.

Hope it answers the question :)

Moty
 
Hi,

The memory leak is through the life cycle of your application.

After the application terminates, the memory space is reused by the OS
(It's the OS responsibility to manage the memory spaces).

But, there are services which in many ways will rarely terminate. In
these cases, static events GC is important especially if you use more
than one AppDomain.

Hope it answers the question :)

Moty- Hide quoted text -

- Show quoted text -
Click to expand...

It makes much sense. That's why I couldn't find any evidence to check
out the detach of the static event. They were always single thread
apps enough for an example.
But you threw out another question, I didn't quite understand that "if
you use more than one AppDomain". Suppose that I got a single thread
app (non-server app) with multiple ADs, I had to subscribe
AppDomain.UnhandledException to handle unknown exceptions, and I also
subcribed Application.ThreadException. In the case, looks like it's
not necessary to detach it since the app temination does good, then
what should I consider with ADs? It there any concept about memory
leak occured in AD?
Thanks.
 
It makes much sense. That's why I couldn't find any evidence to check
out the detach of the static event. They were always single thread
apps enough for an example.
But you threw out another question, I didn't quite understand that "if
you use more than one AppDomain". Suppose that I got a single thread
app (non-server app) with multiple ADs, I had to subscribe
AppDomain.UnhandledException to handle unknown exceptions, and I also
subcribed Application.ThreadException. In the case, looks like it's
not necessary to detach it since the app temination does good, then
what should I consider with ADs? It there any concept about memory
leak occured in AD?
Thanks.
Click to expand...

Hi,

Sorry but what I meant with more than one AppDomain is running more
that one application message queue.

Example:

// Thread 1
Application.ThreadException += ...
Application.Run();
Monitor.Wait(...);

// Thread 2
Application.Exit();

//Thread 3
Application.ThreadException += ...
Application.Run(new Form1());

This sample can lead memory leaks.

Moty
 
Hi,

Sorry but what I meant with more than one AppDomain is running more
that one application message queue.

Example:

// Thread 1
Application.ThreadException += ...
Application.Run();
Monitor.Wait(...);

// Thread 2
Application.Exit();

//Thread 3
Application.ThreadException += ...
Application.Run(new Form1());

This sample can lead memory leaks.

Moty- Hide quoted text -

- Show quoted text -
Click to expand...
From your example, I don't think memory leak would happen.
Click to expand...
Each process (main thread) has its own CLR runtime, so it could manage
its own static events. Then even there are several subscriptions, I
think they are independent, right?
 
The memory leak is through the life cycle of your application.
Click to expand...

But this leak can only occur when the process is shutting down anyway.
But, there are services which in many ways will rarely terminate. In
these cases, static events GC is important especially if you use more
than one AppDomain.
Click to expand...

That is a good point, but the OP was asking about WinForms
applications, and that's the context in which I was questioning
needing to unhook the static event.
 
Each process (main thread) has its own CLR runtime, so it could manage
its own static events. Then even there are several subscriptions, I
think they are independent, right?
Click to expand...

HI,

It's right that each process has it's runtime, but still it is unable
to manage it's static events since GC is done only if there are no
more references pointing to a resource. Thus, static events survive
the GC since there will always be references pointing to them until
the events are unsubscribed.

Moty
 
HI,

It's right that each process has it's runtime, but still it is unable
to manage it's static events since GC is done only if there are no
more references pointing to a resource. Thus, static events survive
the GC since there will always be references pointing to them until
the events are unsubscribed.

Moty- Hide quoted text -

- Show quoted text -
Click to expand...

I knew exactly what you meant. But could you please explain your
example a little bit more? I'm a little confused. How do the
references work in that case? I saw you launched 3 applications, but I
thought they were irrelative. Thanks.
 
Hi,

Check the following example:

public static int Main (string[] args)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(start));
ThreadPool.QueueUserWorkItem(new WaitCallback(start));
Application.Run();
ApplicationContext ac = new ApplicationContext();
return 0;
}

private static void start (object state)
{
Application.ThreadException += new
ThreadExceptionEventHandler(Application_ThreadException);
Application.Run(new Form1());
}

static void Application_ThreadException (object sender,
ThreadExceptionEventArgs e)
{
MessageBox.Show(String.Format("Thread Exception: {0}",
Thread.CurrentThread.ManagedThreadId));
}

Moty
 
Back
Top