OoM error despite having enough memory when patching non-YouTube apps

[JumperREDACTED]

Type

Crash

Bug description

I can patch the YouTube app just fine using ReVanced Manager.
When I try to patch other apps (tested Twitter and Twitch), I get an out of memory error.
According to a resource monitor app I installed, memory used never went over 1500MB (out of 4GB + 2GB memory extension) and I have 20GB+ free storage on both device and SD card.

Possibly a device-related issue for Redmi Note 11, since the only other person with the same issue in the Discord also had one.
The first time I encountered this issue was in early 2022 and I did try again every once in a while, so probably unrelated to specific versions.

Steps to reproduce

(0. Get a Redmi Note 11?)

1. Install ReVanced Manager
2. Get Twitch 15.4.1 apk from apkmirror
3. Attempt patching with default selection of patches

Relevant log output

Writing modified dex files
An error occurred! Aborted
Error:
java.lang.OutOfMemoryError: Failed to allocate a 16 byte allocation with 1555179 free bytes and 1517KB until OOM, target footprint 268435456, growth limit 268435456; giving up on allocation because <1% of heap free after GC.
	at org.jf.dexlib2.dexbacked.DexBuffer.readerAt(DexBuffer.java:145)
	at org.jf.dexlib2.dexbacked.DexBackedDexFile$5.get(DexBackedDexFile.java:313)
	at org.jf.dexlib2.dexbacked.DexBackedDexFile$5.get(DexBackedDexFile.java:308)
	at org.jf.dexlib2.dexbacked.DexBackedField.getName(DexBackedField.java:114)
	at org.jf.dexlib2.base.reference.BaseFieldReference.hashCode(BaseFieldReference.java:44)
	at java.util.HashMap.hash(HashMap.java:338)
	at java.util.LinkedHashMap.get(LinkedHashMap.java:464)
	at org.jf.dexlib2.writer.pool.BaseIndexPool.getItemIndex(BaseIndexPool.java:52)
	at org.jf.dexlib2.writer.pool.FieldPool.getFieldIndex(FieldPool.java:69)
	at org.jf.dexlib2.writer.pool.FieldPool.getFieldIndex(FieldPool.java:40)
	at org.jf.dexlib2.writer.DexWriter.writeEncodedFields(DexWriter.java:776)
	at org.jf.dexlib2.writer.DexWriter.writeClass(DexWriter.java:712)
	at org.jf.dexlib2.writer.DexWriter.writeClasses(DexWriter.java:507)
	at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:355)
	at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:309)
	at lanchon.multidexlib2.DexIO.writeMultiDexDirectoryCommon(DexIO.java:148)
	at lanchon.multidexlib2.DexIO.lambda$writeMultiDexDirectoryMultiThread$0(DexIO.java:92)
	at lanchon.multidexlib2.DexIO$$ExternalSyntheticLambda0.call(Unknown Source:12)
	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
	at java.lang.Thread.run(Thread.java:1012)

Screenshots or videos

No response

Solution

No response

Additional context

MANAGER LOG: https://gist.github.com/JumperREDACTED/6277f64631f818d93465014812cd7120

Redmi Note 11 (2201117TY)
Android 12 SKQ1.211103.001
MIUI Global 13.0.6 Stable 13.0.6.0(SGKEUXM)
(MIUI Optimizations disabled)
Manager 1.3.6
Twitch apk 15.4.1

Acknowledgements

• I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• I have written a short but informative title.
• I filled out all of the requested information in this issue properly.

[oSumAtrIX]

There's little that can be done, this memory footprint is caused by dexlib.

[JumperREDACTED]

There's little that can be done, this memory footprint is caused by dexlib.

So it needs to be reported here? https://github.com/JesusFreke/smali
or is that a different dexlib

I am not really confident in properly decribing the issue or even checking for a duplicate though.

[oSumAtrIX]

@JumperREDACTED Yes, that would be the correct place.

[naxitoo]

@JumperREDACTED Yes, that would be the correct place.

What about this one? https://github.com/google/smali

[oSumAtrIX]

No difference in the source.

[naxitoo]

No difference in the source.

What I mean is, wouldn't it be more convenient to ask on Google's fork instead of the upstream repository, which has not been mantained more than a year ago?

[oSumAtrIX]

Sure

[LisoUseInAIKyrios]

This:

target footprint 268435456, growth limit 268435456; giving up on allocation because <1% of heap free after GC.

Shows the memory limit is 256MB (1024 * 1024 * 256 = 268435456 bytes)

I'm not sure how Manager invokes the patcher, but when launching Java thru command line the default max memory (-Xmx) is 256M

If Manager is using a shell or some other strategy, this can be fixed by adding -Xmx and some appropriate memory limit (1024M should be enough).

[oSumAtrIX]

I am closing this issue as this is something that is rooted in a library that demands this amount of memory to work. Previously we used a different version of the library which did not show this symptom, so this is something that should be figured out in the library. In the meantime an option to use singlethreaded patching is provided to mitigate the issue.