org.acra.ErrorReporter loops until the end of available memory, caused by a java.lang.OutOfMemoryError

[GoogleCodeExporter]

What steps will reproduce the problem?
1. application throws java.lang.OutOfMemoryError
2. Acra crashes with:
java.lang.OutOfMemoryError
    at java.lang.AbstractStringBuilder.enlargeBuffer(AbstractStringBuilder.java:97)
    at java.lang.AbstractStringBuilder.append0(AbstractStringBuilder.java:142)
    at java.lang.StringBuilder.append(StringBuilder.java:124)
    at com.armoredsoft.android.armoreddefense.inapp_google.a.a(SourceFile:46)
    at org.acra.sender.b.a(SourceFile:62)
    at org.acra.ErrorReporter.a(SourceFile:850)
    at org.acra.ErrorReporter.a(SourceFile:960)
    at org.acra.e.run(SourceFile:142)

3.Acra loops until the end of available memory

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Acra 4.2.3, Android 2.1
Please provide any additional information below.
Find attached the crash report generated by ACRA

Original issue reported on code.google.com by toco...@gmail.com on 5 Sep 2011 at 7:36

Attachments:

• acra.xlsx

[GoogleCodeExporter]

The loop is located in one of your own classes:
com.armoredsoft.android.armoreddefense.inapp_google.a.a()

Did you add a custom sender ?

Original comment by kevin.gaudin on 5 Sep 2011 at 7:50

[GoogleCodeExporter]

Sorry for delay
I don't have custom sender

I don't think so. I think the loop is because ACRA is trying to report an 
OutOfMemory exception, and when ACRA is building the report, runs out of memory 
and enters the loop.

This is the "retrace" output for the exception:
java.lang.OutOfMemoryError
    at java.lang.AbstractStringBuilder.enlargeBuffer(AbstractStringBuilder.java:97)
    at java.lang.AbstractStringBuilder.append0(AbstractStringBuilder.java:142)
    at java.lang.StringBuilder.append(StringBuilder.java:124)
    at com.armoredsoft.android.armoreddefense.inapp_google.Security$VerifiedPurchase.void doPost(java.util.Map,java.net.URL,java.lang.String,java.lang.String)(SourceFile:46)
    at org.acra.sender.GoogleFormSender.void send(org.acra.CrashReportData)(SourceFile:62)
    at org.acra.ErrorReporter.void sendCrashReport$5e3fe510(org.acra.CrashReportData)(SourceFile:850)
    at org.acra.ErrorReporter.void checkAndSendReports(android.content.Context,boolean)(SourceFile:960)
    at org.acra.ErrorReporter$ReportsSenderWorker.void run()(SourceFile:142)

Thanks,
Jose

Original comment by toco...@gmail.com on 16 Sep 2011 at 9:27

[GoogleCodeExporter]

I have the same issue... I do not have a custom sender, but I have custom 
variables.

Here is my stacktrace:
java.lang.OutOfMemoryError
1   at java.io.BufferedReader.(BufferedReader.java:87)
2   at org.acra.CrashReportData.load(CrashReportData.java:318)
3   at org.acra.CrashReportData.load(CrashReportData.java:261)
4   at org.acra.ErrorReporter.loadCrashReport(ErrorReporter.java:984)
5   at org.acra.ErrorReporter.checkAndSendReports(ErrorReporter.java:959)
6   at org.acra.ErrorReporter$ReportsSenderWorker.run(ErrorReporter.java:142)

I think that ErrorReporter.loadCrashReport() should have a catch for 
OutOfMemoryError and just fail. Otherwise the app keeps looping error 
reporting. The only way to stop is to shutdown the phone.

Original comment by thier...@gmail.com on 25 Oct 2011 at 3:20

[GoogleCodeExporter]

Same thing is happening to me too, quite often.

Besides catching the OutOfMemoryError caused by 
ErrorReporter.loadCrashReport(), the offending crash report file has to be 
deleted (either immdeiately, or after several failed attempts to send it) so 
that it doesn't cause a repeated OutOfMemoryError  forever, e.g., if it's too 
large.

Original comment by npeer2...@gmail.com on 9 Nov 2011 at 7:17

[GoogleCodeExporter]

Happening here also, >50 times/day.

Original comment by sa...@appsentience.com on 21 Dec 2011 at 7:38

[GoogleCodeExporter]

I modified the trunk to wrap the uncaughtException method content with a try 
catch(Throwable t) which defers the exception management to the native 
UncaughtExceptionHandler. This way, the original application exception will go 
to the Android Market console if your app originates from it.
Be aware that the trunk is unstable for the moment. I have done lots of 
modifications to the application process killing management. Testers are 
welcome ;-)

Kevin

Original comment by kevin.gaudin on 22 Dec 2011 at 9:01

• Changed state: Fixed
• Added labels: Milestone-Release4.3

[GoogleCodeExporter]

Original comment by kevin.gaudin on 7 Sep 2012 at 9:31

• Changed state: Verified