You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Yaron Yeshaya (JIRA)" <ji...@apache.org> on 2012/05/20 16:33:40 UTC
[jira] [Created] (LOG4NET-339) log4net.Appender.EventLogAppende
cause our application to stuck.
Yaron Yeshaya created LOG4NET-339:
-------------------------------------
Summary: log4net.Appender.EventLogAppende cause our application to stuck.
Key: LOG4NET-339
URL: https://issues.apache.org/jira/browse/LOG4NET-339
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows Server 2008 R2 SP1
Reporter: Yaron Yeshaya
Randomly one of our COM Service (.Net 4.0 Windows service that exposes com interface) stop processing com calls. We spoke with Microsoft and sent the the application dump file.
Microsoft claims that from the dump it looks like log4net issue: "we are appending the events 04ACEEE0 00f3ba38 log4net.Appender.EventLogAppender and we are waiting on it (clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x56 --wait).
The issue seems to be coming from log4net."
Did you encountered such an issue?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-339) log4net.Appender.EventLogAppende
cause our application to stuck.
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279908#comment-13279908 ]
Ron Grabowski commented on LOG4NET-339:
---------------------------------------
Can you provide a method name or a better stack trace? The appender eventually calls down to this:
EventLog.WriteEntry(m_applicationName, eventTxt, entryType, eventID, category);
without any fancy locking. How do you know that WriteEntry isn't the problem?
http://svn.apache.org/viewvc/logging/log4net/trunk/src/Appender/EventLogAppender.cs?view=markup
> log4net.Appender.EventLogAppende cause our application to stuck.
> -----------------------------------------------------------------
>
> Key: LOG4NET-339
> URL: https://issues.apache.org/jira/browse/LOG4NET-339
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.10
> Environment: Windows Server 2008 R2 SP1
> Reporter: Yaron Yeshaya
>
> Randomly one of our COM Service (.Net 4.0 Windows service that exposes com interface) stop processing com calls. We spoke with Microsoft and sent the the application dump file.
> Microsoft claims that from the dump it looks like log4net issue: "we are appending the events 04ACEEE0 00f3ba38 log4net.Appender.EventLogAppender and we are waiting on it (clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x56 --wait).
> The issue seems to be coming from log4net."
> Did you encountered such an issue?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-339) log4net.Appender.EventLogAppende
cause our application to stuck.
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284222#comment-13284222 ]
Ron Grabowski commented on LOG4NET-339:
---------------------------------------
I've never really dug deep into memory dump so that wasn't very helpful to me. If you have a lot of control over your environment and you know that all the event log busy work stuff has been setup correctly you could just write your own appender to forward log messages to WriteEntry:
public class ApplicationNameEventLogAppender : AppenderSkeleton
{
protected override void Append(LoggingEvent loggingEvent)
{
EventLog.WriteEntry("ApplicationName", RenderLoggingEvent(loggingEvent), EventLogEntryType.Information);
}
}
That would eliminate log4net's EventLogAppender as the problem.
> log4net.Appender.EventLogAppende cause our application to stuck.
> -----------------------------------------------------------------
>
> Key: LOG4NET-339
> URL: https://issues.apache.org/jira/browse/LOG4NET-339
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.10
> Environment: Windows Server 2008 R2 SP1
> Reporter: Yaron Yeshaya
>
> Randomly one of our COM Service (.Net 4.0 Windows service that exposes com interface) stop processing com calls. We spoke with Microsoft and sent the the application dump file.
> Microsoft claims that from the dump it looks like log4net issue: "we are appending the events 04ACEEE0 00f3ba38 log4net.Appender.EventLogAppender and we are waiting on it (clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x56 --wait).
> The issue seems to be coming from log4net."
> Did you encountered such an issue?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-339) log4net.Appender.EventLogAppende
cause our application to stuck.
Posted by "Yaron Yeshaya (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279980#comment-13279980 ]
Yaron Yeshaya commented on LOG4NET-339:
---------------------------------------
I have the analysis of the memory dump:
Offending stack:
04acee80 752e0bdd ntdll!NtWaitForMultipleObjects+0x15
04acef1c 76e91a2c KERNELBASE!WaitForMultipleObjectsEx+0x100
04acef64 738af2ea kernel32!WaitForMultipleObjectsExImplementation+0xe0 -->wait.
04acefc8 738af118 clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x56 -->wait
04acefe8 738aef58 clr!Thread::DoAppropriateAptStateWait+0x4d
04acf07c 738af019 clr!Thread::DoAppropriateWaitWorker+0x17d
04acf0e8 73989d56 clr!Thread::DoAppropriateWait+0x60
04acf1e8 72d4b77f clr!WaitHandleNative::CorWaitOneNative+0x196
04acf200 72d4b73d mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+0x2b
04acf220 00d70626 mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+0x2d
04acf268 0065ba8e EventService!TraderTools.STPlatform.EventService.SynchronizedQueue.Dequeue()+0x36
04acf2c0 72d4afeb EventService!TraderTools.STPlatform.EventService.EventThread.ThreadProc()+0x4e
04acf2d0 72cd7fc4 mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+0x63
04acf2ec 72cd7f04 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+0xb0
04acf30c 72d4af78 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x2c
04acf324 738721db mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+0x44
04acf334 73894c12 clr!CallDescrWorker+0x33
04acf3b0 73894db4 clr!CallDescrWorkerWithHandler+0x8e
04acf4f4 73894de9 clr!MethodDesc::CallDescr+0x194
04acf510 73980e74 clr!MethodDesc::CallTargetWorker+0x21
04acf71c 739b453a clr!ThreadNative::KickOffThread_Worker+0x1e1
04acf730 739b45bc clr!ManagedThreadBase_DispatchInner+0x5d
04acf7e0 739b4677 clr!ManagedThreadBase_DispatchMiddle+0xcd
04acf840 739b4711 clr!ManagedThreadBase_DispatchOuter+0x5d
04acf864 73980d47 clr!ManagedThreadBase_FullTransitionWithAD+0x37
04acf87c 73980c42 clr!ManagedThreadBase::KickOff+0x15
04acf914 73976580 clr!ThreadNative::KickOffThread+0x23e
04acfbb0 76e9339a clr!Thread::intermediateThreadProc+0x4b
04acfbbc 773c9ed2 kernel32!BaseThreadInitThunk+0xe
04acfbfc 773c9ea5 ntdll!__RtlUserThreadStart+0x70
04acfc14 00000000 ntdll!_RtlUserThreadStart+0x1b
Dumping strings:
04ACEEDC 00f32744 log4net.Core.Level
04ACEEE0 00f3ba38 log4net.Appender.EventLogAppender
04ACEF48 00f91588 log4net.Repository.Hierarchy.DefaultLoggerFactory+LoggerImpl
04ACEF4C 00f91664 log4net.Core.LogImpl
04ACEFB4 00f3ba38 log4net.Appender.EventLogAppender -->implimeting log4net.
04ACF1D0 00f90894 Microsoft.Win32.SafeHandles.SafeWaitHandle
04ACF1F8 00f9087c System.Threading.ManualResetEvent
04ACF218 00f40db0 TraderTools.STPlatform.EventService.SynchronizedQueue
04ACF240 00f40db0 TraderTools.STPlatform.EventService.SynchronizedQueue
04ACF260 00f93034 TraderTools.EventService.PerformanceMonitor.EventServicePM
04ACF274 00f3dfa8 TraderTools.STPlatform.EventService.EventThread
04ACF2B8 010007fc System.Threading.Overlapped
04ACF2F8 00f3e030 System.Threading.ThreadHelper
04ACF590 00f3e044 System.Threading.ThreadStart
> log4net.Appender.EventLogAppende cause our application to stuck.
> -----------------------------------------------------------------
>
> Key: LOG4NET-339
> URL: https://issues.apache.org/jira/browse/LOG4NET-339
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.10
> Environment: Windows Server 2008 R2 SP1
> Reporter: Yaron Yeshaya
>
> Randomly one of our COM Service (.Net 4.0 Windows service that exposes com interface) stop processing com calls. We spoke with Microsoft and sent the the application dump file.
> Microsoft claims that from the dump it looks like log4net issue: "we are appending the events 04ACEEE0 00f3ba38 log4net.Appender.EventLogAppender and we are waiting on it (clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x56 --wait).
> The issue seems to be coming from log4net."
> Did you encountered such an issue?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira