[ https://issues.apache.org/jira/browse/LOG4NET-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671515#action_12671515 ]
Ron Grabowski commented on LOG4NET-198: --------------------------------------- When I run the code below without starting logTimer Environment.WorkingSet stays the same. When I run the code as shown the WorkingSet slowly increases: namespace ConsoleApplication1 { class Program { private static readonly ILog log = LogManager.GetLogger(typeof(Program)); static void Main(string[] args) { XmlConfigurator.Configure(); var logTimer = new Timer(1000); logTimer.Elapsed += delegate { log.Debug("Hello World"); }; logTimer.Start(); var workingSetTimer = new Timer(500); workingSetTimer.Elapsed += delegate { Console.WriteLine(Environment.WorkingSet); }; workingSetTimer.Start(); Console.ReadLine(); } } } When I use the BasicConfigurator with this appender: class NullAppender : IAppender { public void Close() { // empty } public void DoAppend(LoggingEvent loggingEvent) { // empty } public string Name { get { return "NullAppender"; } set { /* empty */ } } } The WorkingSet value remains the same. That leads me to believe that if there is any kind of leak its not in the core log4net code. I also ran this to see if there is a natural increase in memory usage when you're writing to the file system using a typical FileStream due to the Framework's internal buffering: var fs = File.OpenWrite("log.txt"); var sw = new StreamWriter(fs); var logTimer = new Timer(1000); logTimer.Elapsed += delegate { sw.Write("Hello World"); }; logTimer.Start(); There wasn't an increase in the WorkingSet. That's my 15min short dive into the problem. I'm not sure WorkingSet is the best measure for this type of stuff. I ran that code through ANTS Memory Profiler but nothing jumped out at me. I don't think GC.Collect() is the correct fix. If there's a problem it'll most likely be at the appender level. > Memory leak on a very basic code > -------------------------------- > > Key: LOG4NET-198 > URL: https://issues.apache.org/jira/browse/LOG4NET-198 > Project: Log4net > Issue Type: Test > Components: Core > Affects Versions: 1.2.10 > Environment: windows xp sp3 > Reporter: rauzy > Attachments: WindowsFormsApplication1.zip > > > I build a simple form with a single button that start a timer execute every > second, the task of this timer is to execute the following line: > log.Debug("Hello"); > and I observe a memory leak. > See Below. > using System; > using System.Collections.Generic; > using System.ComponentModel; > using System.Data; > using System.Drawing; > using System.Text; > using System.Windows.Forms; > using log4net; > using log4net.Config; > namespace WindowsFormsApplication1 > { > public partial class Form1 : Form > { > private static readonly ILog log = > LogManager.GetLogger(typeof(Form1)); > public Form1() > { > InitializeComponent(); > } > private void button1_Click(object sender, EventArgs e) > { > XmlConfigurator.Configure(); > FreqTimers.Start(); > } > private void FreqTimers_Tick(object sender, EventArgs e) > { > log.Debug("demo"); > } > } > } > with an app.config like > <?xml version="1.0" encoding="utf-8" ?> > <configuration> > <configSections> > <section name="log4net" > type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> > </configSections> > <log4net debug="true"> > <appender name="RollingLogFileAppender" > type="log4net.Appender.RollingFileAppender"> > <file value="C:\\Temp\\TestMailer.log" /> > <appendToFile value="true" /> > <rollingStyle value="Size" /> > <maxSizeRollBackups value="10" /> > <maximumFileSize value="10MB" /> > <staticLogFileName value="true" /> > <layout type="log4net.Layout.PatternLayout"> > <conversionPattern value="%-5p %d - %m %-18.18M %n" /> > </layout> > </appender> > <root> > <level value="DEBUG" /> > <appender-ref ref="RollingLogFileAppender" /> > </root> > </log4net> > </configuration> > If you monitor the application, you see that the memory usage increase. Why? > I can post the source solution if needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.