[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4net-user
Subject:    RE: Uncaught IndexOutOfRangeException in log4net 1.2.9 Beta
From:       "Nicko Cadell" <nicko () neoworks ! com>
Date:       2006-04-21 15:51:41
Message-ID: DDEB64C8619AC64DBC074208B046611C7698B6 () kronos ! neoworks ! co ! uk
[Download RAW message or body]

This is a known issue fixed in log4net 1.2.10. Please download the
latest version from http://logging.apache.org/log4net/downloads.html

The exception is actually coming from an internal error handler. The
Appender must have thrown an exception for this code path to be
activated. The log4net.Util.LogLog.Error is used to log internal errors.

The log4net.Util.LogLog.Error writes to the console, and the
System.Diagnostics.Trace handler. It looks like Console code isn't
working correctly.


This is not recommended but If you must use log4net 1.2.9 then you can
disable the internal error logging by setting the following
<appSettings> in your application's .config file:

<appSettings>
  <add key="log4net.Internal.Quiet" value="true" />
</appSettings>

Cheers,
Nicko


> -----Original Message-----
> From: Ian Dykes [mailto:ian.dykes@esendex.com] 
> Sent: 21 April 2006 16:18
> To: log4net-user@logging.apache.org
> Subject: Uncaught IndexOutOfRangeException in log4net 1.2.9 Beta
> 
> Hi,
> 
> We're in the process of updating our logging from version 
> 1.2.0 beta 8 (DLL version 1.2.0.30714) to the 1.2.9 beta and 
> are experiencing an uncaught error when our test system is 
> placed under load.
> 
> We're running version 1.1 of the MS .Net framework on Windows 
> 2003 Server, and have also seen this on Windows XP Pro SP2.
> 
> We have a server process which catches all exceptions and 
> logs them as errors.  The stack trace we are getting is as follows:
> 
> ERROR[slf5s.PRIORITY]
> (null)[slf5s.NDC]
> 2132[slf5s.THREAD]
> com.esendex.ems.ScheduledSubmissionServer[slf5s.CATEGORY]
> com.esendex.common.statusservice.Status.LogError(:0)[slf5s.LOCATION]
> Error calling ProcessMessages[slf5s.MESSAGE]
> 
> System.IndexOutOfRangeException: Probable I/O race condition 
> detected while copying memory.  The I/O package is not thread 
> safe by default.  In multithreaded applications, a stream 
> must be accessed in a thread-safe way, such as a thread-safe 
> wrapper returned by TextReader's or TextWriter's Synchronized 
> methods.  This also applies to classes like StreamWriter and 
> StreamReader.
> 
> Server stack trace: 
>    at System.Buffer.InternalBlockCopy(Array src, Int32 
> srcOffset, Array dst, Int32 dstOffset, Int32 count)
>    at System.IO.StreamWriter.Write(Char[] buffer, Int32 
> index, Int32 count)
>    at System.IO.TextWriter.WriteLine(String value)
>    at System.IO.SyncTextWriter.WriteLine(String value)
>    at log4net.Util.LogLog.Error(String message, Exception exception)
>    at 
> log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(Loggin
> gEvent loggingEvent)
>    at 
> log4net.Repository.Hierarchy.Logger.CallAppenders(LoggingEvent
>  loggingEvent)
>    at log4net.Repository.Hierarchy.Logger.ForcedLog(Type 
> callerStackBoundaryDeclaringType, Level level, Object 
> message, Exception exception)
>    at log4net.Repository.Hierarchy.Logger.Log(Type 
> callerStackBoundaryDeclaringType, Level level, Object 
> message, Exception exception)
>    at log4net.Core.LogImpl.Debug(Object message)
>    at 
> com.esendex.ems.datamappers.ScheduledSubmissionBatchDM.SelectB
> atchForDateTime(DateTime date)
>    at 
> com.esendex.ems.implementation.facades.ScheduledSubmissionFaca
> deImpl.GetBatchesToSubmit(DateTime date)
>    at 
> com.esendex.ems.facades.ScheduledSubmissionFacade.GetBatchesTo
> Submit(DateTime date)
>    at 
> System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProc
> essMessage(MethodBase mb, Object[] args, Object server, Int32 
> methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
>    at 
> System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcess
> Message(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
> 
> Exception rethrown at [0]: 
>    at 
> System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(
> IMessage reqMsg, IMessage retMsg)
>    at 
> System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(Messag
> eData& msgData, Int32 type)
>    at 
> com.esendex.ems.facades.ScheduledSubmissionFacade.GetBatchesTo
> Submit(DateTime date)
>    at com.esendex.ems.ScheduledSubmissionServer.ProcessMessages()
>    at com.esendex.ems.ScheduledSubmissionServer.Run()
> 
> The server process is logging to one file, while the Debug 
> line (the line "at log4net.Core.LogImpl.Debug(Object 
> message)" in the stack trace) is meant to log to a different 
> file (which other threads will be logging to).  The server 
> code is in a DLL that is late loaded from the GAC by a host 
> EXE program.  This is logging correctly as the above trace is 
> from that log.  The server DLL then calls through to a COM+ 
> component.  The COM+ component late loads an implementation 
> assembly from the GAC.  It is the logging within this 
> implementation DLL that is throwing the exception.
> 
> I'm logging to a log4net.Appender.RollingFileAppender with 
> the following configuration:
> 
> <appender name="EsendexRollingFileAppender" 
> type="log4net.Appender.RollingFileAppender">
> 	<param name="File" value="${log.dir.unix}/${namespace}.txt" />
> 	<param name="AppendToFile" value="true" />
> 	<param name="MaxSizeRollBackups" value="10" />
> 	<param name="MaximumFileSize" value="5000000" />
> 	<param name="RollingStyle" value="Size" />
> 	<param name="StaticLogFileName" value="true" />
> 	<layout type="log4net.Layout.PatternLayout">
> 		<param name="Header" value="---Start of 
> session---\r\n" />
> 		<param name="Footer" value="---End of session---\r\n" />
> 		<param name="ConversionPattern" 
> value="[slf5s.start]%d{DATE}[slf5s.DATE]%n%p[slf5s.PRIORITY]%n
> %x[slf5s.NDC]%n%t[slf5s.THREAD]%n%c[slf5s.CATEGORY]%n%l[slf5s.
> LOCATION]%n%m[slf5s.MESSAGE]%n%n" />
> 	</layout>
> </appender>
> 
> (${log.dir.unix} and ${namespace} are other variables within 
> the config file)
> 
> I've had a look around the known bugs with this version and 
> haven't found a resolution to this.  We are not experiencing 
> this problem with the older version 1.2.0 either.
> 
> Is there anything we can do to stop this exception being thrown?
> 
> Apologies if this is a known problem with a simple 
> resolution, but I've been looking for a solution all day and 
> haven't found anything.
> 
> Regards
> Ian Dykes
>  
> -
>  
> Software Developer
> Esendex Ltd
> 49 Stoney Street
> Nottingham NG1 1LX
>  
> http://www.esendex.com
>  
> Tel: +44 (0) 115 959 7962
> Fax: +44 (0) 115 959 7966
>  
> Esendex voted as one of O2's "50 To Watch In Mobile".  Read 
> the full story at http://www.realbusiness.co.uk/mobile
> 

[prev in list] [next in list] [prev in thread] [next in thread]