ContextInitializer.autoConfig() doesn't close resource that could be leak

[FilenkovMaxim]

implementation 'com.github.tony19:logback-android:1.3.0-2'

Run

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
          .detectAll()
          .penaltyLog()
          .build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
          .detectAll()
          .penaltyLog()
          .build());

ContextInitializer ci = new ContextInitializer(lc);
ci.autoConfig();

got the error

A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
    java.lang.Throwable: Explicit termination method 'close' not called
        at dalvik.system.CloseGuard.open(CloseGuard.java:180)
        at java.util.zip.ZipFile.<init>(ZipFile.java:185)
        at java.util.jar.JarFile.<init>(JarFile.java:199)
        at libcore.net.url.JarURLConnectionImpl.openJarFile(JarURLConnectionImpl.java:136)
        at libcore.net.url.JarURLConnectionImpl.findJarFile(JarURLConnectionImpl.java:125)
        at libcore.net.url.JarURLConnectionImpl.connect(JarURLConnectionImpl.java:82)
        at libcore.net.url.JarURLConnectionImpl.getInputStream(JarURLConnectionImpl.java:215)
        at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
        at ch.qos.logback.classic.util.ContextInitializer.autoConfig(Unknown Source)

[tony19]

I can't reproduce the problem. Can you provide a link to a GitHub repo that exhibits this?

Note that you shouldn't be calling ContextInitializer.autoConfig() because it's already automatically called (hence its name).

[FilenkovMaxim]

Did you set StrictMode?
I call it because I clean log directory after I sent logs to my server.

[tony19]

Did you set StrictMode?

Yes

I call it because I clean log directory after I sent logs to my server.

ContextInitializer.autoConfig() isn't intended to do that.

[FilenkovMaxim]

Ok, I'll try to reproduce this in a blank example and will upload it to github.

[tony19]

I was able to reproduce the issue with some minor modifications to your code.

The GenericConfigurator.doConfigure() methods in logback should be closing the input streams in a finally block (a logback bug), which would resolve the leak issue. In addition, the lc.reset() in resetLogs() should be lc.stop() in your case in order to properly close all logback resources (such as AsyncAppender worker threads).

[FilenkovMaxim]

@tony19 thank you. I'll fix this.

[FilenkovMaxim]

@tony19 I've checked. Without ci.autoConfig(); logback doesn't create new log file until app restart.
If I should not use ci.autoConfig(); how I can start writing logs to new file?

[tony19]

Fixed in v_1.3.0-3

[FilenkovMaxim]

Hello.
I tried
implementation 'com.github.tony19:logback-android:1.3.0-3'
and

LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
    lc.reset();
    lc.stop();

but it still doesn't create new log file until app restart.

[tony19]

@FilenkovMaxim That's unrelated to this issue, which was about a resource leak. With your original code (including ci.autoConfig()), you'll no longer observe the resource-leak exceptions.

Btw, you should replace lc.reset() with lc.stop() (don't do both).

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.