Detach Application.ThreadException Event, really?

[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.

 

[Moty Michaely]

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.

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

 

[Buddhist.CHinA]

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

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.

 

[Moty Michaely]

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.

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

 

[Andy]

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...

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.

 

[Moty Michaely]

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.

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

 

[Buddhist.CHinA]

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 -

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.

 

[Moty Michaely]

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.

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

 

[Buddhist.CHinA]

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 -

From your example, I don't think memory leak would happen.

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?

 

[Andy]

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

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.

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.

 

[Moty Michaely]

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?

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

 

[Buddhist.CHinA]

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 -

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.

 

[Moty Michaely]

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