SQLiteAppender and ProGuard

[dmazzoni]

Issue description

In release builds obfuscated with ProGuard, logging to an SQLiteAppender results in the SQLite database file being created, but no entries are added to it. When ProGuard is disabled logging works as expected.

Logback configuration

The logback configuration is carried out at runtime, without using the logback.xml file. An SQLiteAppender and a LogcatAppender are started and added to the created loggers. The Logcat appender works in both obfuscated and unobfuscated builds, while the SQLite one does not append any entry to the database when using obfuscated builds.

ProGuard rules

The relevant rules in our ProGuard file are:

-keep class org.slf4j.** { *; }
-keep class ch.qos.logback.** { *; }
-keepattributes *Annotation*

We have also tried adding the public modifier after the -keep directive, but to no avail.
Is there any additional SQLite-related rule that we should add?

Environment

Library version: com.github.tony19:logback-android:1.1.1-11 + org.slf4j:slf4j-api:1.7.25
Android version: tested on Android 6.0.1 (LG Nexus 5) and 8.1.0 (Google Pixel 2)

[tony19]

TLDR: Bug found in SQLiteAppender. Will fix in next release.

---

I can confirm an exception in the release/obfuscated build:

05-19 00:05:59.472 6725-6725/tony19.gh.neting.cc.logbackexample I/System.out: 00:05:59,471 |-ERROR in ch.qos.logback.classic.android.SQLiteAppender[DB] - Cannot append event java.lang.IllegalArgumentException: the bind value at index 11 is null
    	at java.lang.IllegalArgumentException: the bind value at index 11 is null
        at 	at android.database.sqlite.SQLiteProgram.bindString(SQLiteProgram.java:164)
        at 	at ch.qos.logback.classic.android.SQLiteAppender.bindCallerData(Unknown Source:16)
        at 	at ch.qos.logback.classic.android.SQLiteAppender.subAppend(Unknown Source:14)
        at 	at ch.qos.logback.classic.android.SQLiteAppender.append(Unknown Source:24)
        at 	at ch.qos.logback.classic.android.SQLiteAppender.append(Unknown Source:2)
        at 	at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(Unknown Source:84)
        at 	at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(Unknown Source:19)
        at 	at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Unknown Source:6)
        at 	at ch.qos.logback.classic.Logger.callAppenders(Unknown Source:5)
        at 	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Unknown Source:15)
        at 	at ch.qos.logback.classic.Logger.filterAndLog_2(Unknown Source:44)
        at 	at ch.qos.logback.classic.Logger.info(Unknown Source:10)
        at 	at tony19.gh.neting.cc.logbackexample.MainActivity$1$1.onClick(Unknown Source:36)
        at 	at android.support.design.widget.Snackbar$1.onClick(Unknown Source:2)
        at 	at android.view.View.performClick(View.java:6294)
        at 	at android.view.View$PerformClick.run(View.java:24770)
        at 	at android.os.Handler.handleCallback(Handler.java:790)
        at 	at android.os.Handler.dispatchMessage(Handler.java:99)
        at 	at android.os.Looper.loop(Looper.java:164)
        at 	at android.app.ActivityThread.main(ActivityThread.java:6494)
        at 	at java.lang.reflect.Method.invoke(Native Method)
        at 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
        at 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)

This occurs because the release apk's Throwable#getstacktrace contains no debug info for determining caller data, so StackTraceElement#getFilename returns null, which is an illegal argument for SQLiteProgram#bindString. I think an appropriate fix is to add null-checks for these bindings, which would allow any debug-enabled apps to continue logging caller data.

[tony19]

Fixed in v_1.1.1-12

[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.