Sign in Register
Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Andy Butland 422 posts 2334 karma points MVP 4x hq c-trib
    Jun 26, 2015 @ 14:46
    Andy Butland
    0

    Investigating memory issue - reporting that "Finalizer thread blocked"

    I'm investigating an issue with a site that is consuming more memory than it should - it ramps up slowly and eventually we need to recycle the app pool.

    Trying to see if I can diagnose anything with Microsoft's Debug Diagnostic tool.

    One issue I can see is in the generated report is that it complains that "the finalizer thread is blocked" and points to the following stack trace:

    [[HelperMethodFrame_1OBJ] (System.Threading.WaitHandle.WaitOneNative)] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+22
mscorlib_ni!System.Threading.WaitHandle.WaitOne(System.TimeSpan, Boolean)+60
mscorlib_ni!System.Threading.WaitHandle.WaitOne(System.TimeSpan)+15
Umbraco.Core.Logging.AsynchronousRollingFileAppender.OnClose()+60
log4net.Appender.AppenderSkeleton.Close()+47
log4net.Appender.AppenderSkeleton.Finalize()+4f
[[DebuggerU2MCatchHandlerFrame]]
[[ContextTransitionFrame]]
[[GCFrame]]

    Which stems from Umbraco's AsynchronousRollingFileAppender implemented for logging with log4net.

    Question then really for anyone who has dug into anything like this, is is this just something that's an artefact of this testing and not something to be concerned with? I would assume that's the case or we'd likely see similar issues on other Umbraco sites. But could it actually be something to be concerned about with regard the memory issues I'm looking into?

    Thanks

    Andy

    Copy Link
  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jun 27, 2015 @ 08:25
    Shannon Deminick
    0

    Hey Andy, this is definitely not a concern regarding memory issues. We've done countless memory dumps when debugging mem issues and the logger has never shown up as a blip on the radar.

    When debugging mem issues, it's best and easiest to take a mem dump when the issues is occurring and then analyzing it. Vs does a really good job of analysing mem dumps for memory analysis.

    Copy Link
  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jun 27, 2015 @ 08:26
    Shannon Deminick
    0

    I'll investigate why your report is complaining about that though to see if that's just a flask positive since we are keeping a thread alive

    Copy Link
  • Andy Butland 422 posts 2334 karma points MVP 4x hq c-trib
    Jun 28, 2015 @ 21:24
    Andy Butland
    0

    Thanks Shannon - I assume it's a false positive simply as if not, we'd likely see issues on our other Umbraco sites, are we're not. But would be good to clear it up given when I do the memory analysis using this tool, this "finalizer thread is blocked" is the only obvious issue that seems to be flagged.

    Andy

    Copy Link
  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jul 01, 2015 @ 09:21
    Shannon Deminick
    0

    No worries Andy, I'll do a bit of research today to see if i can see anything obvious

    Copy Link
  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jul 01, 2015 @ 11:41
    Shannon Deminick
    0

    From the looks of this issue, i think it's just complaining that in the OnClose method it is trying to 

     _manualResetEvent.WaitOne(TimeSpan.FromSeconds(5));

    the debugger is probably complaining about that because that could block the finalizer thread for up to 5 seconds but it will still continue.

    I've just had a look at newer async log4net logging options which uses more current and best practices methods to do the async-ing, so we'll include that with 7.3

    Copy Link
Please Sign in or register to post replies

Write your reply to:

Draft