MokoSan
commented
2 years ago Edited repost of my research from https://github.com/Maoni0/realmon/issues/25
@Maoni0, for the second problem i.e. "disposing" the session multiple times, my guess is this be because the name of the session is hardcoded as MySession here and based on the way you tested the program, multiple of these sessions are being created with the same name which seems like a violation of what's described in the TraceProgrammer's Guide in this that's causing "unexpected" code paths:
"Creates a new TraceEventSession, each session is given a name that is unique ACROSS THE MACHINE. In our case we called our session MySession. Sessions CAN live beyond the lifetime of process that created them, and this name is how you refer to these sessions from other processes besides the process that created them. We also specify a file where the data is to be logged. By convention, these data files use the .ETL (Event Trace Log) suffix."
Solution: Pass in a forced unique session name via a command line argument?
I looked at the tool briefly today and I could see sometimes the memory usage go up pretty quickly (like when I was using one gcmon process to monitor anther gcmon process 😀). a hasty look at the callstacks for VirtualAlloc* in windbg gives me a few categories for committed bytes - some are understandable; others aren't. for example, this is a pretty common callstack -
we are still processing the GC events even though we are not displaying the results because those are not event happening in the process we asked for. these should be dead though since I'm not storing them anywhere. should verify this is the case.
but things like this seem odd -
and I'm seeing many of these (which is odd 'cause we should only be disposing the session once).
would be worthwhile to do a deeper investigation.