Debugging event leaks
Events can be lame. Wonderful, but lame. One thing that bugs me about the subscribe model is that in most of our code we really are just thinking in terms of one subscriber. But the event as a tool encourages thinking only of many subscribers. Into this hole we fall...
The bug is that you have one subscriber to an event, who goes away and comes back later, possibly as a different instance of the same object. Of course he's forgotten to unsubscribe from the event. Meanwhile, the event source is some kind of singleton in your system (in our case it's an expensive-to-create object, lazily initialized and then kept around).
Later, after crash reports come in, you find dozens of zombie consumer objects held in the crypt of the event handler. This wouldn't be so bad, but the zombies clutch in their hands very valuable resources that consume a lot of memory elsewhere.
The object array at 0x3b110b38 is the "crypt," let's see who is in there:
Taking one at random:
A few nice links on the topic are here, which is a nice rundown of strategies to deal with the drawbacks of events, and a class from Jeff Richter here.
The bug is that you have one subscriber to an event, who goes away and comes back later, possibly as a different instance of the same object. Of course he's forgotten to unsubscribe from the event. Meanwhile, the event source is some kind of singleton in your system (in our case it's an expensive-to-create object, lazily initialized and then kept around).
Later, after crash reports come in, you find dozens of zombie consumer objects held in the crypt of the event handler. This wouldn't be so bad, but the zombies clutch in their hands very valuable resources that consume a lot of memory elsewhere.
(output from !gcroot) ... 01acbce4(HistoScanning.Visualization.VizController.VizController)-> 14e13e0c(System.EventHandler`1[[HistoScanning.VizInterfaces.PushToolEventArgs, HistoScanning.VizInterfaces]])-> 3b110b38(System.Object[])
The object array at 0x3b110b38 is the "crypt," let's see who is in there:
0:000> !dumparray 3b110b38 Name: System.Object[] MethodTable: 793042f4 EEClass: 790eda64 Size: 144(0x90) bytes Array: Rank 1, Number of elements 32, Type CLASS Element Methodtable: 79330740 [0] 01acdb9c [1] 0e153f30 [2] 02024884 [3] 0203ddc0 [4] 02056444 [5] 31b35dac [6] 0e51b69c [7] 323258cc [8] 3233c5bc [9] 32644078 [10] 32657a84 [11] 32794b64 [12] 31f88780 [13] 3aa3491c [14] 3aa7c034 [15] 3adda58c [16] 3b110b18 [17] 3b127c80 [18] 3b42a008 [19] 149f03fc [20] 14b0f778 [21] 14e13dec [22] null [23] null [24] null [25] null [26] null [27] null [28] null [29] null [30] null [31] null
Taking one at random:
0:000> !do 0203ddc0
Name: System.EventHandler`1[[HistoScanning.VizInterfaces.PushToolEventArgs, HistoScanning.VizInterfaces]]
MethodTable: 08cadb2c
EEClass: 790c3518
Size: 32(0x20) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
MT Field Offset Type VT Attr Value Name
79330740 40000ff 4 System.Object 0 instance 0203dcdc _target
7932ff98 4000100 8 ...ection.MethodBase 0 instance 00000000 _methodBase
793333ec 4000101 c System.IntPtr 1 instance 33801b8 _methodPtr
793333ec 4000102 10 System.IntPtr 1 instance 0 _methodPtrAux
79330740 400010c 14 System.Object 0 instance 00000000 _invocationList
793333ec 400010d 18 System.IntPtr 1 instance 0 _invocationCount
0:000> !do 0203dcdc
Name: HistoScanning.Prost8.ViewModels.PushToolsViewModel
MethodTable: 251f55b0
EEClass: 2306cf38
Size: 68(0x44) bytes
(C:\Program Files\AMD\HistoScanning\Prost8.ViewModels.dll)
Fields:
MT Field Offset Type VT Attr Value Name
7932ca34 400007e 8 System.Guid 1 instance 0203dce4 uniqueId
793045f0 400007f 4 System.Boolean 1 instance 1 disposed__BackingField
...
Ah. A disposed PushToolsViewModel, the very definition of zombie, along with 20 friends. Back to the original event handler:
0:000> !do 14e13e0c
Name: System.EventHandler`1[[HistoScanning.VizInterfaces.PushToolEventArgs, HistoScanning.VizInterfaces]]
MethodTable: 08cadb2c
EEClass: 790c3518
Size: 32(0x20) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
MT Field Offset Type VT Attr Value Name
79330740 40000ff 4 System.Object 0 instance 14e13e0c _target
7932ff98 4000100 8 ...ection.MethodBase 0 instance 00000000 _methodBase
793333ec 4000101 c System.IntPtr 1 instance 95b1e8 _methodPtr
793333ec 4000102 10 System.IntPtr 1 instance 790fe7b0 _methodPtrAux
79330740 400010c 14 System.Object 0 instance 3b110b38 _invocationList
793333ec 400010d 18 System.IntPtr 1 instance 16 _invocationCount
Examine the _invocationList fields of your events to find these characters. Either make sure consumers unsubscribe, or figure out a time when you can blank out the consumers en masse with a statement like
...
ToolChanged = delegate { };
...
It's good to do that anyway on dispose of the source object, but in my case we can't dispose of it because of cost.A few nice links on the topic are here, which is a nice rundown of strategies to deal with the drawbacks of events, and a class from Jeff Richter here.
posted by Michael Stanton at
1:55 AM
0 Comments
