scrpy cause android ION memory leak very quickly, but ARDC won't(594 objests in size of 7880704 , Total 4681138176)

[RandolphWang]

• [*] I have read the FAQ.
• [*] I have searched in existing issues.

Environment

• OS: [Windows]
• scrcpy version: [e.g. v1.24]
• installation method: [Windows release...]
• device model: Qualcomm SA8295
• Android version: [12]

Describe the bug

size 7880704 ion_dma_buf will occupy about more than 594 times Dma-buf Objects: size flags mode count exp_name ino
07880704 00000002 00080007 00000005 ion_dma_buf|556|vendor.qti.medi|EvtQ_codecPipe 00298486

... Total 976 objects, 5360279552 bytes 594 objests in size of 7880704 , Total 4681138176

although 7880704 is malloc in vendor.qti.medi 556 mediacodec 1254r CHR 10,127 0t0 2208 /dev/ion but it related with main 8274 shell 46r CHR 10,127 0t0 2208 /dev/ion

and pid 8274 is scrpcy. 10-19 09:45:53.030 shell 8274 8274 D AndroidRuntime: >>>>>> START com.android.internal.os.RuntimeInit uid 2000 <<<<<< 10-19 09:45:53.029 shell 8274 8274 I app_process: type=1400 audit(0.0:4679): avc: denied { read } for name="u:object_r:odsign_prop:s0" dev="tmpfs" ino=3541 scontext=u:r:shell:s0 tcontext=u:object_r:odsign_prop:s0 tclass=file permissive=1 10-19 09:45:53.029 shell 8274 8274 I app_process: type=1400 audit(0.0:4680): avc: denied { open } for path="/dev/properties/u:object_r:odsign_prop:s0" dev="tmpfs" ino=3541 scontext=u:r:shell:s0 tcontext=u:object_r:odsign_prop:s0 tclass=file permissive=1 10-19 09:45:53.034 shell 8274 8274 I AndroidRuntime: Using default boot image 10-19 09:45:53.034 shell 8274 8274 I AndroidRuntime: Leaving lock profiling enabled 10-19 09:45:53.029 shell 8274 8274 I app_process: type=1400 audit(0.0:4681): avc: denied { getattr } for path="/dev/properties/u:object_r:odsign_prop:s0" dev="tmpfs" ino=3541 scontext=u:r:shell:s0 tcontext=u:object_r:odsign_prop:s0 tclass=file permissive=1 10-19 09:45:53.029 shell 8274 8274 I app_process: type=1400 audit(0.0:4682): avc: denied { map } for path="/dev/properties/u:object_r:odsign_prop:s0" dev="tmpfs" ino=3541 scontext=u:r:shell:s0 tcontext=u:object_r:odsign_prop:s0 tclass=file permissive=1 10-19 09:45:53.035 shell 8274 8274 W app_process: ART APEX data files are untrusted. 10-19 09:45:53.036 shell 8274 8274 I app_process: Core platform API reporting enabled, enforcing=false 10-19 09:45:53.102 shell 8274 8274 D app_process: Time zone APEX ICU file found: /apex/com.android.tzdata/etc/icu/icu_tzdata.dat 10-19 09:45:53.102 shell 8274 8274 D app_process: I18n APEX ICU file found: /apex/com.android.i18n/etc/icu/icudt68l.dat 10-19 09:45:53.120 shell 8274 8274 D ProcessState: Binder ioctl to enable oneway spam detection failed: Invalid argument 10-19 09:45:53.120 shell 8274 8274 D AndroidRuntime: Calling main entry com.genymobile.scrcpy.Server

we find it can be reproduced by open scrcpy and plug out the USB cable, at the sametime we will send some canoe messages. but it can't reproduce by ARDC.

BRs [email protected]

[rom1v]

scrcpy uses the MediaCodec API (a priori, correctly, you can check the code), so the memory leak is in the encoder implementation (in the device ROM).

[RandolphWang]

I still don't think it is MediaCodec bug, it may scrcpy enter some infinite loop, and in some unexpect case (unplug USB cable) scrcpy didn't stop dequeueoutputbuffer and queueinputbuffer. May you help to check the code logic?

in about 30 seconds Wed Oct 19 09:57:54 CST 2022 Wed Oct 19 09:58:28 CST 2022

ion_dma_buf 07880704 00000002 00080007 00000005 ion_dma_buf|556|vendor.qti.medi|EvtQ_codecPipe 00389352 increase 307 to 594

scrcpy(pid 8274) hold ion fd increase from 346 to 585. main 8274 shell 46r CHR 10,127 0t0 2208 /dev/ion

BRs [email protected]

[RandolphWang]

i am not sure your logic, but I guess it may caused by outputBufferId == INFO_TRY_AGAIN_LATER == -1 then in you logic, your will never release if (outputBufferId >= 0) { codec.releaseOutputBuffer(outputBufferId, false);

Mediacodec may have memory leak bug, it should not so quickly, in about 30s, more than 2.2GB ION memory lost.

Added in API level 16

public static final int INFO_TRY_AGAIN_LATER If a non-negative timeout had been specified in the call to dequeueOutputBuffer(MediaCodec.BufferInfo, long), indicates that the call timed out.

Constant Value: -1 (0xffffffff)

[RandolphWang]

hi， Romain I can 100% reproduce this issue. both on unbuntu and windows in v1.24 and if I kill -9 all com.genymobile.scrcpy.Server related process, the ION will decrease to normal value.

and when I try to compile it to add some deubug log i meet a compile error BUILD FAILED in 1m 49s [1/2] Linking target app/scrcpy. FAILED: server/scrcpy-server /mnt/46e7a692-417c-441e-8e75-2f07f7629e88/work/scrcpy/scrcpy/server/./scripts/build-wrapper.sh /mnt/46e7a692-417c-441e-8e75-2f07f7629e88/work/scrcpy/scrcpy/server server/scrcpy-server release

I am not good at setting compile environment， so could you give me a debug version scrcpy, then I can help you to catch log and find the root cause together.

BRs [email protected]

[RandolphWang]

hi, Romain may you help to give a debug version, many of my colleagues still like to use scrcpy, Many thanks! BRs Ran

[rom1v]

i am not sure your logic, but I guess it may caused by outputBufferId == INFO_TRY_AGAIN_LATER == -1 then in you logic, your will never release

You don't need to release in that case: https://developer.android.com/reference/android/media/MediaCodec#dequeueOutputBuffer(android.media.MediaCodec.BufferInfo,%20long)

Mediacodec may have memory leak bug, it should not so quickly, in about 30s, more than 2.2GB ION memory lost.

I can 100% reproduce this issue. both on unbuntu and windows in v1.24 and if I kill -9 all com.genymobile.scrcpy.Server related process, the ION will decrease to normal value.

Still compatible with the hypothesis of a leak in the MediaCodec backend implementation. If this was in scrcpy, this would happen with all encoders.

may you help to give a debug version

You can build a version: https://github.com/Genymobile/scrcpy/blob/master/BUILD.md

A debug version in itself will not help you (it adds only few additional logs), you need to add logs yourself in the code and compile it anyway.

[RandolphWang]

hi，Romain

my colleague find that it may caused by our unplug usb event USB_STATE=DISCONNECTED was not sent out.

So i still have a question that does com.genymobile.scrcpy.Server or com.genymobile.scrcpy.CleanUp will handle this USB event or not? if scrcpy don't recieve the this event， what will happen？

BRs Ran

[rom1v]

my colleague find that it may caused by our unplug usb event USB_STATE=DISCONNECTED was not sent out.

This event is not sent (and may not be sent) by scrcpy, since USB disconnections kills the scrcpy-server process.

[RandolphWang]

thanks Romain!

so does scrcpy-server register an exit, to notify usb process to kill itself when unplug?

I am wondering if any other app need to do the something.

BRs Ran

[RandolphWang]

hi, Romain may you tell us how USB disconnections kills the scrcpy-server process? many thanks. BRs Ran

[rom1v]

Because if you run adb shell some_program, some_program is killed when you unplug the device.

[unwynd]

Hi @RandolphWang, Have you managed to fix this issue?

[springeryuan]

Hi @RandolphWang , have you reached any conclusion about this issue?

[yale8809]

Hi @RandolphWang @rom1v , the same question as above. It seems many people run into this issue. Still no conclusion it's scrcpy issue or codec issue.

[coder-lc]

Hi @RandolphWang @rom1v ,same question occur.please help share updates on issues,thanks!

[rom1v]

Try using adb shell screenrecord /sdcard/file.mp4, do you reproduce?

[coder-lc]

Hi @rom1v ,Screenrecord was not used when the issue occurred, and it has not been reproduced so far. What is the meaning of using adb shell screenrecord /sdcard/file.mp4?

[rom1v]

To record the screen without using scrcpy at all, and see if the problem occurs.