[Vm-dev] Re: SegmentationFault in with OmniBrowser

Philippe Marschall philippe.marschall at gmail.com
Thu May 24 18:04:51 UTC 2007


2007/5/23, Ted Neward <ted at tedneward.com>:
>
> There are a few Java assemblers out there. And, of course, various Java
> compilers have had bugs in them over the years, too, though few and far
> between.
>
> Thing is, though, you don't even need a bad compiler or assembler to
> generate .class files that violate one another. Easy proof:
>
> public class A { public int a; }
> public class B {
>   public static void main(String[] args) {
>     A a = new A();
>     a.a = 12;
>   }
> }
>
> Compile both (javac A.java B.java). Now modify A to be:
>
> public class A { private int a; }
>
> Now just recompile A (javac A.java). Run B (java B). Boom.

Thank you, this is a very good example of what I mean. The VM
_detects_ (!!!) that your bytecodes don't match your classes and
throws a normal Java exception (java.lang.IllegalAccessError, subclass
of java.lang.IncompatibleClassChangeError subclass of
java.lang.LinkageError) at which point normal Java exception handling
kicks in. Compare that with Squeak: signal 11. Imagine you had such a
method in your startup list.

For more fun we can even remove the field a and get an instance of
java.lang.NoSuchFieldError (also subclass of
java.lang.IncompatibleClassChangeError)

you can modify B to

public class B {
    public static void main(String[] args) {
        try {
            A a = new A();
            a.a = 12;
        } catch (IncompatibleClassChangeError e) {
            System.out.println("it looks like you modified A");
        }
    }
}

and your programm continues normally.

Cheers
Philippe

> So the idea that the compiler (in the traditional C/C++/Java/C# sense) can
> somehow track and prevent all sorts of errors is, to my mind, a foolish and
> dangerous one. A post-compilation, pre-execution verifier is a Good
> Thing(TM), IMHO.
>
> FYI, inside the .NET CLR, the verifier and the JIT compiler are deeply and
> tightly twisted against one another; the JVM verifier and JIT compilers
> aren't quite so incestuously combined, but still pretty closely related.
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
> > -----Original Message-----
> > From: vm-dev-bounces at lists.squeakfoundation.org [mailto:vm-dev-
> > bounces at lists.squeakfoundation.org] On Behalf Of tim Rowledge
> > Sent: Tuesday, May 22, 2007 11:04 AM
> > To: Squeak Virtual Machine Development Discussion
> > Subject: Re: [Vm-dev] Re: SegmentationFault in with OmniBrowser
> >
> >
> >
> > On 22-May-07, at 10:56 AM, Philippe Marschall wrote:
> >
> >
> > >
> > > Java has a bytecode verifyer to prevent these problems with zero
> > > runtime cost (if you don't count class loading). Squeak could have the
> > > same.
> > Absolutely irrelevant to the problem in question. Smalltalk has a
> > 'bytecode verifier' too - it's called the compiler. It too makes sure
> > the bytecodes are suitable as it 'loads' them.
> >
> > The problem is that if some *other* tool is generating bytecodes it
> > can make 'bad' ones that will stomp over other objects. Just as in
> > java you could etc etc. At least, I assume java could have a tool to
> > generate bytecodes and run them? I wouldn't really know, never having
> > had anything to do with it.
> >
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Gotta run, the cat's caught in the printer.
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007
> > 2:01 PM
> >
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.6/815 - Release Date: 5/22/2007
> 3:49 PM
>
>
>


More information about the Vm-dev mailing list