harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Fri, 28 Jul 2006 18:29:13 GMT
On 28 Jul 2006 15:35:42 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:

> >It reminds me of one usecase, when a 'maybe-commercial' server running
> >a JVM accepts deployments of JAR files and cannot predict what users
> >deploy. So, not-to-crash on SOE is a matter of security for the
> >server. And this is really important to eliminate this
> >vulnerability. Readjusting stack size does not work here.

My impression is that most commercial server design is insulated from
vulnerability from user code and similar security breaches by allowing only
the process hosting the user application to go down, not the entire web
server. Since the user code causing unbounded recursion is an
application bug, it may not be worthwhile to try to prevent this failure.
The failure that would be good to guard against is the one that happens
though the user code is correct, ie., from a genuine lack of stack
resources. It would be nice to see a real use case for this. We don't have
to be perfect. No VM is.

 For failures in native code, there are some choices..
1. Tuning by choosing stack and guard sizes from the command line. This
is  limited on Windows due to interference from the inbuilt Windows stack
growth algorithm. But something like this could yield a good average size
2. Set the exception info on the thread when the exception cannot be raised
and check for it and raise it later. This may be the simplest. Is there a
reason ( other than choice of approach ) why we can't do this?
3. Proactively check in the Jit to not allow SOE to happen by querying the
VM and taking some recovery action eg., failing the compile, disabling
optimizations, compiling with a down level compiler etc. This is a lot of
work. And only the jit( eg., not the verifier ) can do this. Without seeing
a real use case or reliability target, I don't know if it is necessary to do
so much. There is a priority question too.


Egor Pasko, Intel Managed Runtime Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message