Calling handleException() with a caught exception kills the whole app

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add a catch clause where I expect an exception may be generated
2. call ErrorReporter.getInstance().handleException(e)
3. ACRA never returns control to my code, so the app is effectively dead

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

I expect that after calling handleException(), my code will resume so it can 
continue executing. Instead, it seems that my app's thread is killed.

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

4.2.3 on Android 2.2 (Froyo)

Please provide any additional information below.

Sample code which causes the problem:

  boolean parseComplete = false;
  db.beginTransaction();
  try {
      // some code which might fail

      parseComplete = true;             
  } catch (Exception e) {
      // I expect this exception to occur; I want to log it with ACRA
      // and then carry on
      Log.e("MyApp", "Parse failure");
      ErrorReporter.getInstance().handleException(e);

      // this line of code is never reached
      e.printStackTrace();
  } finally {
      // this code is never executed either!
      Log.i("YNAB", "in 'finally' clause");
      if (parseComplete)
          db.setTransactionSuccessful();
      db.endTransaction();
  }

Original issue reported on code.google.com by info%gra...@gtempaccount.com on 6 Sep 2011 at 9:00

[GoogleCodeExporter]

I'm seeing the same issue on Android 2.2. For me it is locking up in the 
LogCatCollector.collectLogCat function line 89. It appears that the LogCat 
process is run (via Runtime.exec) and the output is collected via a stream 
(Process.getInputStream). When that stream is finally empty (presumably when 
LogCat has delivered the full history), readLine is expected to return a 
<null>, but in my case it is not doing that and the process just sits and waits.

Why this would happen sometimes and not others is a mystery. I am executing 
this particular call on the UI thread if that is relevant. I will try moving it 
to a background thread anyway to prevent an application hang even if the 
logging fails.

Here is the full stack for a hung thread:

OSFileSystem.readImpl(int, byte[], int, int) line: not available [native 
method] 
OSFileSystem.read(int, byte[], int, int) line: 118  
ProcessManager$ProcessInputStream(FileInputStream).read(byte[], int, int) line: 
312 
InputStreamReader.read(char[], int, int) line: 275  
BufferedReader.fillBuf() line: 155  
BufferedReader.readLine() line: 386 
LogCatCollector.collectLogCat(String) line: 89  
ErrorReporter.retrieveCrashData(Context) line: 434  
ErrorReporter.handleException(Throwable, ReportingInteractionMode) line: 722    
ErrorReporter.handleException(Throwable) line: 773  

Original comment by rupert.r...@gmail.com on 18 Jan 2012 at 10:59

[GoogleCodeExporter]

I think I have some possible answers: In the case where you don't specify the 
-t option (to limit the number of log messages), the -d option (don't wait for 
new messages) is not added automatically to the command line by Acra, which 
means that LogCat does not terminate by default (hence no <null>).

Adding -d to Acra during initialization (or specifying -t explicitly) fixes 
this.

In addition to that, if the RADIO_EVENT log contains absolutely nothing 
(possibly because of aggressive filtering), the call to readLine appears to 
hang regardless of the LogCat command line settings. I have removed it from my 
list of data to retrieve for now (I target tablet devices anyway). I think this 
was the cause of the problem coming and going - radio events had not occurred 
on all devices.

Original comment by rupert.r...@gmail.com on 18 Jan 2012 at 12:00