Archie Cobbs wrote:
Gary Benson wrote:
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot
Gary Benson wrote:
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable? My reasoning was that the code
was added to
Gary Benson wrote:
Archie Cobbs wrote:
Gary Benson wrote:
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through
Gary Benson wrote:
Gary Benson wrote:
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did
On Fri, 2006-01-13 at 08:48 +0100, Mark Wielaard wrote:
Maybe we can again special case that security check by doing a
this.getClass().getClassLoader() == null?
Hmmm, no, that doesn't work since getClassLoader() will trigger a
security check. Nasty...
I see you solved this by just doing an
Guilhem Lavaux wrote:
Gary Benson wrote:
FWIW I was able to push IBM's JRE into an infinite loop with this
test, so it would appear to be vulnerable to the same class of
problems even if not this actual problem.
BTW, Gary your test triggers a really nasty VerifyError in kaffe so
maybe
On Thu, 2006-01-12 at 14:15 +, Gary Benson wrote:
FWIW I was able to push IBM's JRE into an infinite loop with this
test, so it would appear to be vulnerable to the same class of
problems even if not this actual problem.
Another test which completely kicks us out. Actually it's an stack
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did with the system properties (i.e. introduce a
Gary Benson wrote:
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did with the system properties
Mark Wielaard wrote:
Maybe we can again special case that security check by doing a
this.getClass().getClassLoader() == null?
Hmmm, no, that doesn't work since getClassLoader() will trigger a
security check. Nasty...
That's what VMStackWalker.getClassLoader() is for... you could use it.
Archie Cobbs wrote:
Mark Wielaard wrote:
Maybe we can again special case that security check by doing a
this.getClass().getClassLoader() == null?
Hmmm, no, that doesn't work since getClassLoader() will trigger a
security check. Nasty...
That's what VMStackWalker.getClassLoader() is
Gary Benson wrote:
Guilhem Lavaux wrote:
Gary Benson wrote:
FWIW I was able to push IBM's JRE into an infinite loop with this
test, so it would appear to be vulnerable to the same class of
problems even if not this actual problem.
BTW, Gary your test triggers a really nasty VerifyError in
Gary Benson wrote:
Gary Benson wrote:
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did with the
Guilhem Lavaux wrote:
Gary Benson wrote:
Guilhem Lavaux wrote:
Gary Benson wrote:
FWIW I was able to push IBM's JRE into an infinite loop with this
test, so it would appear to be vulnerable to the same class of
problems even if not this actual problem.
BTW, Gary your test triggers a
On Sat, Jan 14, 2006 at 12:16:48AM +0100, Dalibor Topic wrote:
I have found what was causing the VerifyError in kaffe. I have fixed it
and now it passes your test successfully with the help of latest patches
from Jeroen.
Thanks to you all !
Wow, that was awesome to watch ... GNU
Hi Jeroen,
On Fri, 2006-01-13 at 07:54 +0100, Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce the
problem on IKVM as well. The attach Classpath patch fixing things,
although past 0.20 I think we should refactor the security properties
like I did with
Guilhem Lavaux wrote:
I have stumbled across a bug probably shared by all VMs using GNU
Classpath. In Apache Ant a SecurityManager is installed to be able
to execute java application without forking the VM. Thanks to the SM
exiting a VM is forbidden and so ant is protected from the
On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote:
After fixing some IKVM specific bugs, I was able to run the testcase
succesfully with only the attached GNU Classpath fix.
Can you please see if this patch improves things for you as well?
No, same StackOverFlow with jamvm or cacao.
Gary Benson wrote:
Guilhem Lavaux wrote:
3) One solution of the problem is to load some core classes. But it
will appear quite soon that some other classes may also be loaded
for really wicked applications. It is a limitative solution and I
would not support it.
Yes. Exactly which
Hi Jeroen,
On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote:
After fixing some IKVM specific bugs, I was able to run the testcase
succesfully with only the attached GNU Classpath fix.
That patch is obviously correct. Please do check this in even if other
runtimes are still broken :)
Jeroen Frijters wrote:
Gary Benson wrote:
Guilhem Lavaux wrote:
3) One solution of the problem is to load some core classes. But it
will appear quite soon that some other classes may also be loaded
for really wicked applications. It is a limitative solution and I
would not support it.
Yes.
Guilhem Lavaux wrote:
I must say that I don't understand this problem.
Me neither...
I do not think it is strictly linked to the VM.
I have produced an artificial stack trace by tweaking kaffe's VM.
Normally this stack trace is hidden by the VM and
replaced by a NoClassDefFoundError. Here
Guilhem Lavaux wrote:
I have stumbled across a bug probably shared by all VMs using GNU
Classpath. In Apache Ant a SecurityManager is installed to be able to
execute java application without forking the VM. Thanks to the SM
exiting a VM is forbidden and so ant is protected from the
23 matches
Mail list logo
