OOM while submitting crash reports

[pfn]

I don't know why my acra crash reports can be so huge at times, but I get the following crash stack on occasion.

java.lang.OutOfMemoryError: Failed to allocate a 33554444 byte allocation with 16437126 free bytes and 15MB until OOM   at java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:163)    at java.io.BufferedInputStream.read(BufferedInputStream.java:295)   at java.io.InputStreamReader.read(InputStreamReader.java:231)   at java.io.BufferedReader.fillBuf(BufferedReader.java:145)  at java.io.BufferedReader.readChar(BufferedReader.java:263)     at java.io.BufferedReader.read(BufferedReader.java:253)     at org.acra.CrashReportPersister.load(CrashReportPersister.java:173)    at org.acra.CrashReportPersister.load(CrashReportPersister.java:77)     at org.acra.SendWorker.checkAndSendReports(SendWorker.java:140)     at org.acra.SendWorker.run(SendWorker.java:77)

The fix is to add bis.mark(0) at

https://github.com/ACRA/acra/blob/master/src/main/java/org/acra/CrashReportPersister.java#L75

[pfn]

Alternatively, you could just mark with default buffer size, rather than Int.max_value immediately before that.

[pfn]

Also, why is ebcdic being checked at all? Android devices don't generate ebcdic, what drove the inclusion of this encoding check?

[william-ferguson-au]

Good question. It's been there since the very first version of the CrashReportData class.
@pyricau can you provide any clarity?
@pfn want to provide a pull request that cleans it up?

[pyricau]

@KevinGaudin introduced ebcdic in 2011 when ACRA started reading from Properties: 2f6b62a

I'm guessing this would be come copy paste from another codebase :) .

[william-ferguson-au]

Thanks @pyricau
@pfn wnat to provide a pull request that cleans it up?

[pfn]

yep, incoming