how much is this covered by https://codereview.chromium.org/2817663004 ?

This is probably just a case where we need to catch a bunch of exceptions and ignore the issue because the framework is broken, rather than propagating them.

Yeah, do we have a good way of finding the Java exception stack traces though?

For the cases where particular framework methods are backed by complex often-vendor-specific code (and media codecs seem especially likely here) I suspect that chromium just needs to unfortunately move toward catching Exception and hoping for the best, at which point the stack isn't that important.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding OWNERS. qinmin@, mcasas@ would you be opposed to catching all exceptions from the framework in VideoCaptureCamera(2).java?

I see crashes in clank, so I'm removing the webview component.

VideoCaptureDeviceFactoryAndroid::GetSupportedFormats goes through a lot of chromium Java code before it calls into framework stuff. So we should probably be careful about what we catch. And we can't know what to catch without seeing the Java stacks, since we can't predict OEM badness a priori. So I think the first step here would be to expose these as Java crashes, then sift through the crashes we get and decide which to ignore.

If it's reasonably easy to get this to actually be an uncaught java exception then that's fine, but I was assuming that this was going to be difficult (as most of them are), and if so I'm not sure it's worth it.

If we're going to try to guard from bad OEM changes then we should be putting the try-catch handling around the specific places where we call framework APIs that might explode (so that we can try our best to handle the failure rationally), *not* here at the top level where we call from C++ into Java anyway.

Right, but there's a lot of different APIs being called in VideoCaptureCamera{,2}.java, and I don't think we can know ahead of time which ones might explode.

Or we could catch for every API, which would be ugly, but easier to implement.

Yes, what I'm proposing is that for every call we make to the framework in this known-to-be-dodgy area, if it is both:

1) plausibly going to throw an undocumented exception maybe

and 2) possible to do something other than crash, e.g. assume "not supported" or "give up" in some noncrashy way

then we should wrap it in a generic try-catch block that handles a wide range of possible exceptions. :(

Looking into the various APIs, many of them call back into native after very little Java code. Would you expect OEM native badness to manifest by throwing Java exceptions through the API? I would think they would just crash in native.

Well clearly something is throwing java exceptions, and the normal expectation with JNI code *is* that the native code throws java exceptions instead of crashing in native, especially for errors that map reasonably to java exceptions (e.g. bad parameters and the like, not "we randomly dereferenced a bad pointer" which would indeed just segfault).

If there's a reasonably straightforward way for us to actually get the java exception stacks here then go ahead, but this doesn't seem worth doing any radical restructuring of the calling code for.