En tant que hack, ce fut un beaucoup plus facile à faire que ce que je pensais que ce serait. Depuis c'est un hack rapide, je ne fais pas les choses comme faire en sorte que la trace de la pile est assez profond avant déréférencement du tableau, etc. J'inséré ce qui suit dans mon signé constructeur de Applet:
log.info("Old security manager = " + System.getSecurityManager());
System.setSecurityManager(new SecurityManager() {
@Override
public void checkAccess(final Thread t) {
StackTraceElement[] list = Thread.currentThread().getStackTrace();
StackTraceElement element = list[3];
if (element.getMethodName().equals("interrupt")) {
log.info("CheckAccess to interrupt(Thread = " + t.getName() + ") - "
+ element.getMethodName());
dumpThreadStack(Thread.currentThread());
}
super.checkAccess(t);
}
});
et la méthode dumpThreadStack est la suivante:
public static void dumpThreadStack(final Thread thread) {
StringBuilder builder = new StringBuilder('\n');
try {
for (StackTraceElement element : thread.getStackTrace()) {
builder.append(element.toString()).append('\n');
}
} catch (SecurityException e) { /* ignore */ }
log.info(builder.toString());
}
Je ne pourrais jamais, bien sûr, laisser cela dans le code de production, mais il suffisait de me dire exactement ce qui était à l'origine un fil interrupt() que je ne m'y attendais pas. C'est-à-dire, avec ce code en place, j'obtiens un vidage de pile pour chaque appel à Thread.interrupt().
Je peux penser à quelques façons de le faire avec une complexité différente et des performances différentes. Est-ce une chose ponctuelle de trouver un bug ou est-ce quelque chose que vous voulez en production? – Fredrik
Ceci est principalement quelque chose que je veux comme une chose ponctuelle, mais quelque chose que je sais que je vais vouloir utiliser de temps en temps. Si elle était assez amicale, je la laisserais dans le code de production, mais désactivée comme un mode supplémentaire de débogage à distance (via les journaux) à utiliser en cas de besoin. – Eddie