Leak in SystemJobService

[rickytribbia]

Hi everyone,

we're using WorkManager in an app in which we've also LeakCanary configured and we always receive this warning after a run of each Periodic Worker:

	16:49:08.888	LeakCanary		​
====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

774 bytes retained by leaking objects
Signature: 6491376cfe66b1cac0d47b3ae180fd902719aa5
┬───
│ GC Root: Global variable in native code
│
├─ android.app.job.JobService$1 instance
│    Leaking: UNKNOWN
│    Retaining 802 B in 15 objects
│    Anonymous subclass of android.app.job.IJobService$Stub
│    this$0 instance of androidx.work.impl.background.systemjob.SystemJobService
│    ↓ JobService$1.this$0
│                   ~~~~~~
╰→ androidx.work.impl.background.systemjob.SystemJobService instance
​     Leaking: YES (ObjectWatcher was watching this because androidx.work.impl.background.systemjob.SystemJobService
​     received Service#onDestroy() callback)
​     Retaining 774 B in 14 objects
​     key = 155d4c85-1073-4df1-bd0f-250b40c959c8
​     watchDurationMillis = 5248
​     retainedDurationMillis = 246
​     mApplication instance of xx.yy.MyApp
​     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 23
Build.MANUFACTURER: alps
LeakCanary version: 2.6
App process name: xx.yy.MyApp
Stats: LruCache[maxSize=3000,hits=101,misses=300675,hitRate=0%]
RandomAccess[bytes=11383030,reads=300675,travel=696095628841,range=23369842,size=28770980]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 202141 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-xx.yy.MyApp/2021-03-08_16-45-32_740.
hprof
Heap dump timestamp: 1615218548838
Heap dump duration: 13889 ms
====================================

WorkManager library in use: androidx.work:work-rxjava2:2.5.0
LeakCanary library in use: com.squareup.leakcanary:leakcanary-android:2.6

Any advice? Did you see this warning yet?

I don't know if can be a useful info, but the app we're developing is a system app used on embedded device (Android based, obviously)

[calren]

@rickytribbia I don't believe we've seen any similar issues. Are you able to reproduce the behavior in a non-systems app running on a Android phone (not an embedded device)? If not, I suspect the problem is not with the workmanager library.

[rickytribbia]

Hi Calren, thank you for your answer.
I don't know if you're experienced with LeakCanary; its heap analysis result print any dependencies between an instance of a retained object and the GC Root.

In the log that I printed before you can see that there aren't any classes of my app between the retained object and the root, so I have no entrypoint to investigate deep to this leak.
What do you think about it? Where could I check if my code retains something about workmanager instances (androidx.work.impl.background.systemjob.SystemJobService, I think)?

[calren]

If possible, can you try installing your app on an Android phone and see if the same leak canary warnings are surfaced?

I suspect the leak might be coming from the embedded device and not the WorkManager library itself, so it'd be good to check if leak canary still reports the same warnings on devices not running a modified version of Android.

[rickytribbia]

 Hi Calren,
we've tried to install our app on an Android phone: the same leak canary warnings was nevers surfaced, but the scenario is really different (our app acts as a system app, so have extended permissions), so our app in any Job runned by WorkManager always returns errors and the Job/Worker fails instantly.

Have you any advice? Another possible clue could be that we use Dagger for dependency injection also into our Worker?

[ArcherEmiya05]

I also had this issue. Regarding the statement by @calren

I suspect the leak might be coming from the embedded device

Uhm, leak root cause should not depend on a device and its never been that way?

[ArcherEmiya05]

This is what I get sometimes

04-28 10:58:52.125 13357-13357/com.myapp.name D/LeakCanary: ​
    ┬───
    │ GC Root: Global variable in native code
    │
    ├─ android.app.job.JobService$1 instance
    │    Leaking: UNKNOWN
    │    Retaining 602 B in 13 objects
    │    Anonymous subclass of android.app.job.IJobService$Stub
    │    this$0 instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
    │    ↓ JobService$1.this$0
    │                   ~~~~~~
    ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
    ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
    ​     ActivityThread)
    ​     Retaining 574 B in 12 objects
    ​     key = 54f18ba8-4533-4b95-8def-6b19b6e79481
    ​     watchDurationMillis = 5260
    ​     retainedDurationMillis = 254
    ​     mApplication instance of com.myapp.name.App
    ​     mBase instance of android.app.ContextImpl
    
    METADATA
    
    Build.VERSION.SDK_INT: 21
    Build.MANUFACTURER: Xiaomi
    LeakCanary version: 2.7
    App process name: com.myapp.name
    Stats: LruCache[maxSize=3000,hits=84,misses=122288,hitRate=0%]
    RandomAccess[bytes=11522584,reads=122288,travel=37581525864,range=42112035,size=55145753]
    Heap dump reason: 1 retained objects, app is not visible
    Analysis duration: 32830 ms

[Cassers]

Something similar happens to me in my application

  06-29 19:38:12.834 19354-19354/com.bastechsolutions.swiftcountandroid D/LeakCanary: ​
      ┬───
      │ GC Root: Global variable in native code
      │
      ├─ android.app.job.JobService$1 instance
      │    Leaking: UNKNOWN
      │    Retaining 792 B in 13 objects
      │    Anonymous subclass of android.app.job.IJobService$Stub
      │    this$0 instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
      │    ↓ JobService$1.this$0
      │                   ~~~~~~
      ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
      ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
      ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
      ​     ActivityThread)
      ​     Retaining 764 B in 12 objects
      ​     key = 2bf8f741-1b37-48bd-9ca1-4a13752ad556
      ​     watchDurationMillis = 5222
      ​     retainedDurationMillis = 217
      ​     mApplication instance of com.bastechsolutions.swiftcountandroid.AppDelegate
      ​     mBase instance of android.app.ContextImpl
      
      METADATA

      Build.VERSION.SDK_INT: 23
      Build.MANUFACTURER: BLU
      LeakCanary version: 2.7
      App process name: com.bastechsolutions.swiftcountandroid
      Stats: LruCache[maxSize=3000,hits=96,misses=26206,hitRate=0%]
      RandomAccess[bytes=2616381,reads=26206,travel=9053088550,range=15789858,size=21467640]
      Heap dump reason: 1 retained objects, app is not visible
      Analysis duration: 342982 ms

This only happens to me on a specific cell phone that I use to optimize my applications, I think the error comes out because the device has very low performance.

The device in which it happens to me is a Blue Dash G and has the following characteristics:

Screen: 5 ", 480 x 854 pixels
Processor: Mediatek MT6580 1.3GHz
RAM: 512MB
Storage: 4GB
Expansion: microSD

Camera: 5 MP
Battery: 2000 mAh
OS: Android 6.0
Profile: 9.8 mm
Weight: 157g

[kmayoral]

Here is a dump of my reproduction of the issue as well (as this is still happening):

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

2243 bytes retained by leaking objects
Signature: 953feb82863ec1b7cb6fcf77def88fd9aec7bd
┬───
│ GC Root: Java local variable
│
├─ java.lang.Thread thread
│ Leaking: UNKNOWN
│ Retaining 47.7 kB in 380 objects
│ Thread name: 'pool-10-thread-1'
│ ↓ Thread.<Java Local>
│ ~~~~~~~~~~~~
├─ com.google.android.datatransport.runtime.scheduling.jobscheduling.
│ JobInfoSchedulerService$$ExternalSyntheticLambda0 instance
│ Leaking: UNKNOWN
│ Retaining 3.8 kB in 32 objects
│ f$0 instance of com.google.android.datatransport.runtime.scheduling.
│ jobscheduling.JobInfoSchedulerService
│ ↓ JobInfoSchedulerService$$ExternalSyntheticLambda0.f$0
│ ~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.
​ JobInfoSchedulerService instance
​ Leaking: YES (ObjectWatcher was watching this because com.google.android.
​ datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​ received Service#onDestroy() callback and Service not held by
​ ActivityThread)
​ Retaining 2.2 kB in 17 objects
​ key = 814cc92e-4087-400f-9ab2-7bc5d971018a
​ watchDurationMillis = 5599
​ retainedDurationMillis = 556
​ mApplication instance of com.mycompany.android.App
​ mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do
not have control over.
See https://square.github.
io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong
reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 31
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.mycompany.android
Stats: LruCache[maxSize=3000,hits=4454,misses=259618,hitRate=1%]
RandomAccess[bytes=13015376,reads=259618,travel=184478677083,range=60464600,size
=70558998]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 17591 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-co.mycompany.
android/2022-01-04_10-48-37_439.hprof
Heap dump timestamp: 1641322146281
Heap dump duration: 11154 ms
====================================

The only relevant details that I can discern is this error message:

ObjectWatcher was watching this because com.google.android.
​ datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​ received Service#onDestroy() callback and Service not held by
​ ActivityThread

[caosc900224]

 I can reproduce the same issue on multiple device, I received this warning after run of each Periodic Worker or Enqueued Jobservice, any suggestion for the issue?

com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
​ Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
​ jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
​ ActivityThread)

[kazimdsaidul]

749 bytes retained by leaking objects
Signature: 99e784c1433b5477fe40e3ebca5ffce0e9dd16
┬───
│ GC Root: System class
│
├─ android.content.res.ResourcesImpl class
│    Leaking: NO (a class is never leaking)
│    ↓ static ResourcesImpl.mAppContext
│                           ~~~~~~~~~~~
├─ android.app.ContextImpl instance
│    Leaking: UNKNOWN
│    Retaining 2.0 kB in 13 objects
│    mOuterContext instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
│    ContextImpl.mOuterContext is an instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.
│    JobInfoSchedulerService
│    ↓ ContextImpl.mOuterContext
│                  ~~~~~~~~~~~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
​     ActivityThread)
​     Retaining 749 B in 6 objects
​     key = 4aabceb8-2d2b-4070-b145-d412c58e3bca
​     watchDurationMillis = 135034
​     retainedDurationMillis = 130029
​     mApplication instance of com.sundarban.deliveryman.app.BaseApplication
​     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.7
App process name: com.sundarban.deliveryman.debug
Stats: LruCache[maxSize=3000,hits=3378,misses=88914,hitRate=3%]
RandomAccess[bytes=4167110,reads=88914,travel=43953220991,range=25986646,size=33102335]
Heap dump reason: user request
Analysis duration: 6558 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.sundarban.deliveryman.debug/2022-03-09_12-24-58_395.
hprof
Heap dump timestamp: 1646807108270
Heap dump duration: 2847 ms

[pseandersson]

Any solutions to @kazimdsaidul leak?

[SeniorZhai]

Anyone have a solution?

┬───
│ GC Root: Thread object
│
├─ java.lang.Thread instance
│    Leaking: UNKNOWN
│    Retaining 18.0 kB in 501 objects
│    Thread name: 'pool-6-thread-1'
│    ↓ Thread<Java Local>
│            ~~~~~~~~~~~~
├─ com.google.android.datatransport.runtime.scheduling.jobscheduling.
│  JobInfoSchedulerService$$ExternalSyntheticLambda0 instance
│    Leaking: UNKNOWN
│    Retaining 3.3 kB in 30 objects
│    f$0 instance of com.google.android.datatransport.runtime.scheduling.
│    jobscheduling.JobInfoSchedulerService
│    ↓ JobInfoSchedulerService$$ExternalSyntheticLambda0.f$0
│                                                        ~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.
​  JobInfoSchedulerService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.android.
​     datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​     received Service#onDestroy() callback and Service not held by
​     ActivityThread)
​     Retaining 1.8 kB in 15 objects
​     key = 2aaf8ae9-f257-49d7-aa77-08d528827eff
​     watchDurationMillis = 5551
​     retainedDurationMillis = 549
​     mApplication instance of one.mixin.android.MixinApp
​     mBase instance of android.app.ContextImpl

METADATA

Build.VERSION.SDK_INT: 31
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.9.1
App process name: one.mixin.messenger
Class count: 27917
Instance count: 281753
Primitive array count: 181885
Object array count: 43108

[js361014]

I had tested workmanager on https://github.com/RachmadAgungL/Tugas6-1918070-RachmadAgungL/ and the same issue occurred.

[ivannatividad]

Same here, is there anyone able to figure out the issue?

    ┬───
    │ GC Root: System class
    │
    ├─ android.content.res.ResourcesImpl class
    │    Leaking: NO (a class is never leaking)
    │    ↓ static ResourcesImpl.mAppContext
    │                           ~~~~~~~~~~~
    ├─ android.app.ContextImpl instance
    │    Leaking: UNKNOWN
    │    Retaining 2.0 kB in 13 objects
    │    mOuterContext instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
    │    ContextImpl.mOuterContext is an instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.
    │    JobInfoSchedulerService
    │    ↓ ContextImpl.mOuterContext
    │                  ~~~~~~~~~~~~~
    ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
    ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
    ​     ActivityThread)
    ​     Retaining 749 B in 6 objects
    ​     key = 106b88b8-9fc8-4bb1-bc67-f720d79fdf2f
    ​     watchDurationMillis = 10041
    ​     retainedDurationMillis = 5040
    ​     mBase instance of android.app.ContextImpl
    ====================================
    0 LIBRARY LEAKS
    
    A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
    See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
    ====================================
    0 UNREACHABLE OBJECTS
    
    An unreachable object is still in memory but LeakCanary could not find a strong reference path
    from GC roots.
    ====================================
    METADATA
    
    Please include this in bug reports and Stack Overflow questions.
    
    Build.VERSION.SDK_INT: 30
    Build.MANUFACTURER: Xiaomi
    LeakCanary version: 2.7
    Stats: LruCache[maxSize=3000,hits=3381,misses=202478,hitRate=1%]
    RandomAccess[bytes=10806583,reads=202478,travel=110618093912,range=40792679,size=51604394]
    Heap dump reason: user request
    Analysis duration: 15401 ms
    Heap dump timestamp: 1657242946237
    Heap dump duration: 3515 ms
    ====================================

[WilsonScott]

any solution here ?