You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mike Matrigali <mi...@sbcglobal.net> on 2005/11/01 01:54:41 UTC
is getAllStackTraces() something we are allowed to call from the
server given the recent SecurityManager changes?
Francois Orsini (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12356460 ]
>
> Francois Orsini commented on DERBY-666:
> ---------------------------------------
>
> The new J2SE 5.0 has some new API to dump individual or all threads' stracktrace running in a JVM - There is a new notion of StackTraceElement object which represent a stack frame and can be output'ed as a String....
>
> So you can get all frames of a particular thread's stack dump as well as for all threads in the JVM.
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getStackTrace()
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getAllStackTraces()
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StackTraceElement.html
>
> Thread(s) stack dumps can also be performed on the command line using 'jstack' (1.5) utility to dump all the JVM's thread stack traces given a JVM pid.
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html
>
> fyi.
>
>
>>Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock
>>----------------------------------------------------------------------------------------------
>>
>> Key: DERBY-666
>> URL: http://issues.apache.org/jira/browse/DERBY-666
>> Project: Derby
>> Type: Improvement
>> Components: Store
>> Versions: 10.1.1.0
>> Reporter: Bryan Pendleton
>> Priority: Minor
>
>
>>I was reading http://www.linux-mag.com/content/view/2134/ (good article, btw!), and it says:
>>
>>> The next two properties are needed to diagnose concurrency (locking and deadlock) problems.
>>>
>>> *derby.locks.monitor=true logs all deadlocks that occur in the system.
>>> *derby.locks.deadlockTrace=true log a stack trace of all threads involved in lock-related rollbacks.
>>
>>It seems, that, in my environment, the deadlockTrace property does not log a stack trace of *all* threads involved in the deadlock.
>>Instead, it only logs a stack trace of the *victim* thread involved in the deadlock.
>>I think it would be very useful if the derby.locks.deadlockTrace setting could in fact log a stack trace of all involved threads.
>>In a posting to derby-dev, Mike Matrigali noted that an earlier implementation of a similar feature had to be removed because it was too expensive in both time and space, but he suggested that there might be several possible ways to implement this in an acceptably efficient manner:
>>
>>>A long time ago there use to be room in each lock to point at a
>>>stack trace for each lock, but that was removed to optimize the size
>>>of the lock data structure which can have many objects outstanding.
>>>And creating and storing the stack for every lock was incredibly slow
>>>and just was not very useful for any very active application. I think
>>>I was the only one who ever used it.
>>>
>>>The plan was sometime to add a per user data structure which could be
>>>filled in when it was about to wait on a lock, which would give most of what is interesting in a deadlock.
>>>
>>>The current deadlockTrace is meant to dump the lock table out to derby.log when a deadlock is encountered.
>>>
>>>I agree getting a dump of all stack traces would be very useful, and
>>>with the later jvm debug interfaces may now be possible - in earlier
>>>JVM's there weren't any java interfaces to do so. Does anyone have
>>>the code to donate to dump all thread stacks to a buffer?
>>
>>Mike also suggested a manual technique as a workaround; it would be useful to put this into the documentation somewhere, perhaps on the page which documents derby.locks.deadlockTrace? Here's Mike's suggestion:
>>
>>>What I do if I can reproduce easily is set try to catch the wait by
>>>hand and then depending on the environment either send the magic
>>>signal or hit ctrl-break in the server window which will send the JVM
>>>specific thread dumps to derby.log.
>>
>>The magic signal, btw, is 'kill -QUIT', at least with Sun JVMs in my experience.
>
>
Re: is getAllStackTraces() something we are allowed to call from
the server given the recent SecurityManager changes?
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Francois Orsini wrote:
> if permission is granted as part of the security policies I would think
> so - it will call the appropriate permission check on the security
> manager installed...
For any method call that requires a security permission it can (most
likely) always be used in Derby. Things to consider if such a method
call is to be used are:
- Is it required for running Derby, or only for a sub-feature within
Derby? E.g. in this case it seems only to be needed if debugging lock
deadlocks.
- How risky is granting that permission to a consumer of Derby?
E.g. we could code Derby so that it was required that it be granted
permission to read and write all system properties. That may be seen as
risky to a user of Derby, so instead Derby is coded so that only
granting permission to read properties starting with 'derby.' is required.
Ideally we want to a have situation when a user can grant Derby a
minimal set of permissions that matches their required use of Derby.
When using a such a method call, it must be called in a in a privleged
block.
I plan to provide as part of DERBY-615 documentation with details of
this and existing uses of methods requiring permission.h
Dan.
Re: is getAllStackTraces() something we are allowed to call from the server given the recent SecurityManager changes?
Posted by Francois Orsini <fr...@gmail.com>.
if permission is granted as part of the security policies I would think so -
it will call the appropriate permission check on the security manager
installed...
from the Javadoc:
-----------------------
If there is a security manager, then the security manager's checkPermission
method is called with a RuntimePermission("getStackTrace") permission as
well as RuntimePermission("modifyThreadGroup") permission to see if it is ok
to get the stack trace of all threads.
Throws:
SecurityException - if a security manager exists and its checkPermission
method doesn't allow getting the stack trace of thread.
On 10/31/05, Mike Matrigali <mi...@sbcglobal.net> wrote:
>
>
>
> Francois Orsini (JIRA) wrote:
> > [
> http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12356460]
> >
> > Francois Orsini commented on DERBY-666:
> > ---------------------------------------
> >
> > The new J2SE 5.0 has some new API to dump individual or all threads'
> stracktrace running in a JVM - There is a new notion of StackTraceElement
> object which represent a stack frame and can be output'ed as a String....
> >
> > So you can get all frames of a particular thread's stack dump as well as
> for all threads in the JVM.
> >
> >
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getStackTrace()
> >
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getAllStackTraces()
> >
> > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StackTraceElement.html
> >
> > Thread(s) stack dumps can also be performed on the command line using
> 'jstack' (1.5) utility to dump all the JVM's thread stack traces given a
> JVM pid.
> > http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html
> >
> > fyi.
> >
> >
> >>Enhance derby.locks.deadlockTrace to print stack traces for all threads
> involved in a deadlock
>
> >>----------------------------------------------------------------------------------------------
> >>
> >> Key: DERBY-666
> >> URL: http://issues.apache.org/jira/browse/DERBY-666
> >> Project: Derby
> >> Type: Improvement
> >> Components: Store
> >> Versions: 10.1.1.0 <http://10.1.1.0>
> >> Reporter: Bryan Pendleton
> >> Priority: Minor
> >
> >
> >>I was reading http://www.linux-mag.com/content/view/2134/ (good article,
> btw!), and it says:
> >>
> >>> The next two properties are needed to diagnose concurrency (locking
> and deadlock) problems.
> >>>
> >>> *derby.locks.monitor=true logs all deadlocks that occur in the system.
> >>> *derby.locks.deadlockTrace=true log a stack trace of all threads
> involved in lock-related rollbacks.
> >>
> >>It seems, that, in my environment, the deadlockTrace property does not
> log a stack trace of *all* threads involved in the deadlock.
> >>Instead, it only logs a stack trace of the *victim* thread involved in
> the deadlock.
> >>I think it would be very useful if the derby.locks.deadlockTrace setting
> could in fact log a stack trace of all involved threads.
> >>In a posting to derby-dev, Mike Matrigali noted that an earlier
> implementation of a similar feature had to be removed because it was too
> expensive in both time and space, but he suggested that there might be
> several possible ways to implement this in an acceptably efficient manner:
> >>
> >>>A long time ago there use to be room in each lock to point at a
> >>>stack trace for each lock, but that was removed to optimize the size
> >>>of the lock data structure which can have many objects outstanding.
> >>>And creating and storing the stack for every lock was incredibly slow
> >>>and just was not very useful for any very active application. I think
> >>>I was the only one who ever used it.
> >>>
> >>>The plan was sometime to add a per user data structure which could be
> >>>filled in when it was about to wait on a lock, which would give most of
> what is interesting in a deadlock.
> >>>
> >>>The current deadlockTrace is meant to dump the lock table out to
> derby.log when a deadlock is encountered.
> >>>
> >>>I agree getting a dump of all stack traces would be very useful, and
> >>>with the later jvm debug interfaces may now be possible - in earlier
> >>>JVM's there weren't any java interfaces to do so. Does anyone have
> >>>the code to donate to dump all thread stacks to a buffer?
> >>
> >>Mike also suggested a manual technique as a workaround; it would be
> useful to put this into the documentation somewhere, perhaps on the page
> which documents derby.locks.deadlockTrace? Here's Mike's suggestion:
> >>
> >>>What I do if I can reproduce easily is set try to catch the wait by
> >>>hand and then depending on the environment either send the magic
> >>>signal or hit ctrl-break in the server window which will send the JVM
> >>>specific thread dumps to derby.log.
> >>
> >>The magic signal, btw, is 'kill -QUIT', at least with Sun JVMs in my
> experience.
> >
> >
>
>