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 wa
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 real
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 system
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 k
GNU Classpath 0.20 released
GNU Classpath, essential libraries for java, is a project to create
free core class libraries for use with runtimes, compilers and tools
for the java programming language.
The GNU Classpath developer snapshot releases are not directly aimed
at the end user but are mean
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.getClassLoade
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.
-Archi
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 prop
Hi hackers,
The CVS tree has been tagged for both trunk and generics branch the
final make distcheck is running and will be uploaded in a minute to
ftp://ftp.gnu.org/gnu/classpath/
Official release announcement is in the works and will follow in a
couple of hours. But please feel free to go crazy
Tom Tromey wrote:
Your patch looks like it would help, but it doesn't address all the
issues. It seems reasonable to use it as an interim solution though.
It sounds like by default we're using 127.0.0.1 -- does this happen
with the JDK as well?
Sun's JDK? Works nicely with java.rmi.server.hostna
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
> gn
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
--- Comment #4 from stephan at apache dot org 2006-01-13 11:34 ---
Part of the problem is that the Available task doesn't call
AntClassLoader.cleanup().
I filed a bug against Ant, see
http://issues.apache.org/bugzilla/show_bug.cgi?id=38260
--
http://gcc.gnu.org/bugzilla/show_bug.cg
Quoting Jeroen Frijters ([EMAIL PROTECTED]):
> > FWIW, last time I had problems similar to the one being
> > discussed it was because classpath's default application classloader
> > calls checkPackageAccess() before giving the bootstrap classloader
> > a chance to load the class, instead of the o
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
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
16 matches
Mail list logo
