Increase storage for Java exception information.

Increase storage for Java exception information.

Nested exceptions have multiple stack traces with the most important one at the end.

BUG=389474
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=280793

[Fredrik Öhrn, 2014-06-26 15:09:36]

With nested exceptions the stack trace can get rather large, limiting the string
to only 1024 chars in the crash report is not nearly enough to pinpoint the real
problem.

I think switching to strcpy and keeping all of it would be a good idea but I
assume someone put in a limit for a good reason so I'm just increasing it to 4k
to hopefully cover most cases.

E.g. the following nested crash requires 2k:

java.lang.RuntimeException: Unable to resume activity
{com.opera.browser.beta/com.opera.android.ChromiumActivity}:
java.lang.RuntimeException: Could not dispatch event: class vb to handler
[EventHandler public void sj.a(vb)]
       at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:2774)
       at
android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2803)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1238)
       at android.os.Handler.dispatchMessage(Handler.java:102)
       at android.os.Looper.loop(Looper.java:136)
       at android.app.ActivityThread.main(ActivityThread.java:5001)
       at java.lang.reflect.Method.invokeNative(Native Method)
       at java.lang.reflect.Method.invoke(Method.java:515)
       at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
       at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
       at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.RuntimeException: Could not dispatch event: class vb to
handler [EventHandler public void sj.a(vb)]
       at bpi.a(OperaSrc:444)
       at bpi.b(OperaSrc:374)
       at bpi.a(OperaSrc:355)
       at bpi.c(OperaSrc:324)
       at ol.d(OperaSrc:91)
       at ol.a(OperaSrc:83)
       at qb.a(OperaSrc:63)
       at qb.a(OperaSrc:76)
       at qb.a(OperaSrc:36)
       at rg.R(OperaSrc:1616)
       at rg.onResume(OperaSrc:3138)
       at com.opera.android.ChromiumActivity.onResume(OperaSrc:99)
       at
android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1192)
       at android.app.Activity.performResume(Activity.java:5310)
       at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:2764)
       ... 11 more
Caused by: java.lang.ArithmeticException: divide by zero
       at sj.a(OperaSrc:293)
       at java.lang.reflect.Method.invokeNative(Native Method)
       at java.lang.reflect.Method.invoke(Method.java:515)
       at bpn.a(OperaSrc:89)
       at bpi.b(OperaSrc:372)
       ... 24 more

[nyquist, 2014-06-26 18:20:23]

The CL description is very short and does not explain why this is needed.

Could you please file a tracking bug for this where you describe why you want
this, and where we could discuss the likely fallout of this change?

[Fredrik Öhrn, 2014-06-27 09:17:57]

Posted a bug and elaborated the description a bit.

[Feng Qian, 2014-06-27 17:42:03]

On 2014/06/27 09:17:57, Fredrik Öhrn wrote:
> Posted a bug and elaborated the description a bit.

Thanks for the bug and patch.

I looked over the code with Tommy offline. I felt the client side is OK to
increase to 4K as long as the program is not running after allocating memory.

[Fredrik Öhrn, 2014-06-30 12:18:17]

On 2014/06/27 17:42:03, Feng Qian wrote:
> On 2014/06/27 09:17:57, Fredrik Öhrn wrote:
> > Posted a bug and elaborated the description a bit.
> 
> Thanks for the bug and patch.
> 
> I looked over the code with Tommy offline. I felt the client side is OK to
> increase to 4K as long as the program is not running after allocating memory.

It stops right after, CheckException follows up the call to
set_java_exception_info with CHECK(FALSE);

[nyquist, 2014-07-01 00:10:00]

Given server-side is also OK with this; lgtm.

[Fredrik Öhrn, 2014-07-01 08:10:17]

Thanks everyone for the prompt review.

[Fredrik Öhrn, 2014-07-01 08:10:22]

The CQ bit was checked by ohrn@opera.com

[commit-bot: I haz the power, 2014-07-01 08:10:44]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ohrn@opera.com/358853002/1

[commit-bot: I haz the power, 2014-07-01 10:03:56]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)

[commit-bot: I haz the power, 2014-07-01 10:08:58]

Change committed as 280793