SegmentationFault in with OmniBrowser

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

SegmentationFault in with OmniBrowser

Damien Cassou-3
 
Hi,

you will find here http://damien.cassou.free.fr/crashing.zip an image
which makes the VM segfault. To reproduce:

- Open the image
- Open an 'image browser' from the world menu->open...
- Choose a class and click on one of the 3 filters 'instance' '?' or 'class'.

The VM say:

Segmentation fault

2032029316 [] in OBMetaNode>childrenForNode:
2032030488 [] in Collection>gather:
2032030004 OrderedCollection>do:
2032029408 [] in Collection>gather:
2032029500 >streamContents:
2032029224 Collection>gather:
2032028672 OBMetaNode>childrenForNode:
2032028580 OBNode>childNodes
2032028488 OBColumn>getChildren
2032027384 OBColumn>basicParent:
2032027108 OBColumn>parent:
2032027200 [] in OBColumnPanel>selected:
2032026924 Object>ifNotNilDo:
2032025812 OBColumnPanel>selected:
2032025720 OBColumnPanel>selectionChanged:


The problem is that I can easily reproduce the crash. Just take a
squeak-dev-beta-123 from
http://damien.cassou.free.fr/squeak-dev/beta/, and use the 'Package
Universe Browser' to upgrade to latest OB ('update list from network',
'select all upgrades' 'install selection').

Can somebody help me?


--
Damien Cassou
Reply | Threaded
Open this post in threaded view
|

Re: SegmentationFault in with OmniBrowser

Andreas.Raab
 
Damien Cassou wrote:
> The problem is that I can easily reproduce the crash. Just take a
> squeak-dev-beta-123 from
> http://damien.cassou.free.fr/squeak-dev/beta/, and use the 'Package
> Universe Browser' to upgrade to latest OB ('update list from network',
> 'select all upgrades' 'install selection').
>
> Can somebody help me?

Easy. Since the crash is reproducable there is a good chance the
compiler got confused. Looking at the crash dump we can see that
OBButtonModel triggers it upon a push so changing it to:

push
        ContextPart runSimulated:[bar push: self].

has a very good chance to trigger such problems. And indeed: Once you do
this you get an error saying that instances of OBModalFilter aren't
indexable which is raised during simulating OBModalFilter>>selection:.
Looking at the bytecodes (or the decompile) of that method shows that
there is indeed a major problem, plus in a couple of other methods
(noteParent:child: for example).

How it got into this state is a great question, though. Somewhere,
somehow your system is badly screwed up. Given that you have some fairly
experimental Monticello changes in there I think it's a fair guess to
assume that those might be causing the problem.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Damien Cassou-3
 
Hi Andreas,

2007/5/19, Andreas Raab <[hidden email]>:

> Damien Cassou wrote:
> > The problem is that I can easily reproduce the crash. Just take a
> > squeak-dev-beta-123 from
> > http://damien.cassou.free.fr/squeak-dev/beta/, and use the 'Package
> > Universe Browser' to upgrade to latest OB ('update list from network',
> > 'select all upgrades' 'install selection').
> >
> > Can somebody help me?
>
> Easy. Since the crash is reproducable there is a good chance the
> compiler got confused. Looking at the crash dump we can see that
> OBButtonModel triggers it upon a push so changing it to:
>
> push
>         ContextPart runSimulated:[bar push: self].
>
> has a very good chance to trigger such problems. And indeed: Once you do
> this you get an error saying that instances of OBModalFilter aren't
> indexable which is raised during simulating OBModalFilter>>selection:.
> Looking at the bytecodes (or the decompile) of that method shows that
> there is indeed a major problem, plus in a couple of other methods
> (noteParent:child: for example).


Not that easy to me. I did not understand a word of what you explained.


> How it got into this state is a great question, though. Somewhere,
> somehow your system is badly screwed up. Given that you have some fairly
> experimental Monticello changes in there I think it's a fair guess to
> assume that those might be causing the problem.

You should not assume I have a special Monticello version, it's not
the case. I have the Monticello included in 3.10 (maybe this one is
experimental, I don't know).

So, is there any problem with OmniBrowser or is it a problem with that
particular image and the way I upgrade it?


--
Damien Cassou
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Lukas Renggli
 
> > has a very good chance to trigger such problems. And indeed: Once you do
> > this you get an error saying that instances of OBModalFilter aren't
> > indexable which is raised during simulating OBModalFilter>>selection:.
> > Looking at the bytecodes (or the decompile) of that method shows that
> > there is indeed a major problem, plus in a couple of other methods
> > (noteParent:child: for example).
>
>
> Not that easy to me. I did not understand a word of what you explained.

The compiled method accesses a non-existing instance-variable.

> > How it got into this state is a great question, though. Somewhere,
> > somehow your system is badly screwed up. Given that you have some fairly
> > experimental Monticello changes in there I think it's a fair guess to
> > assume that those might be causing the problem.
>
> You should not assume I have a special Monticello version, it's not
> the case. I have the Monticello included in 3.10 (maybe this one is
> experimental, I don't know).

This probably has to do with the recent changes of Monticello that
somehow changes the way how code is loaded and changes the
change-notification mechanism. It works in 3.9.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Damien Cassou-3
 
2007/5/22, Lukas Renggli <[hidden email]>:

> > > has a very good chance to trigger such problems. And indeed: Once you do
> > > this you get an error saying that instances of OBModalFilter aren't
> > > indexable which is raised during simulating OBModalFilter>>selection:.
> > > Looking at the bytecodes (or the decompile) of that method shows that
> > > there is indeed a major problem, plus in a couple of other methods
> > > (noteParent:child: for example).
> >
> >
> > Not that easy to me. I did not understand a word of what you explained.
>
> The compiled method accesses a non-existing instance-variable.


Much clearer :-) However, when methods access a non existing instance
variable, I think it should not crash the VM with a segfault.


> > > How it got into this state is a great question, though. Somewhere,
> > > somehow your system is badly screwed up. Given that you have some fairly
> > > experimental Monticello changes in there I think it's a fair guess to
> > > assume that those might be causing the problem.
> >
> > You should not assume I have a special Monticello version, it's not
> > the case. I have the Monticello included in 3.10 (maybe this one is
> > experimental, I don't know).
>
> This probably has to do with the recent changes of Monticello that
> somehow changes the way how code is loaded and changes the
> change-notification mechanism. It works in 3.9.

I think Keith's changes have NOT been integrated into 3.10.


--
Damien Cassou
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

timrowledge
 

On 22-May-07, at 7:23 AM, Damien Cassou wrote:

>
>
> Much clearer :-) However, when methods access a non existing instance
> variable, I think it should not crash the VM with a segfault.

Lovely idea. But....
Building bytecodes is just like using assembler; you can corrupt  
anything. Normally the compiler generates the correct, safe, code but  
if you're using some other tool that can be persuaded to pop the  
stack and save to x'th instance var ofan object that has only x-1,  
then you're in trouble because you've almost certainly stomped on the  
header of the next object in memory. Sure, we could make the basic  
routines check the bounds every time. Care to imagine the performance  
impact?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Ornerythologists study bad tempered birds


Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

johnmci
 
Well I did some work with the VW primitive interface, beyond the  
disclaimer of saying if you use this interface you void all warrenty  
support etc etc, we found
that the paranoid apis would check everything for validity, thus the  
prim call would take *forever*, doing say a dot product sum was  
outweight by many microseconds
by the code sanity checking the data items.

On May 22, 2007, at 8:10 AM, tim Rowledge wrote:

>
> On 22-May-07, at 7:23 AM, Damien Cassou wrote:
>
>>
>>
>> Much clearer :-) However, when methods access a non existing instance
>> variable, I think it should not crash the VM with a segfault.
>
> Lovely idea. But....
> Building bytecodes is just like using assembler; you can corrupt  
> anything. Normally the compiler generates the correct, safe, code  
> but if you're using some other tool that can be persuaded to pop  
> the stack and save to x'th instance var ofan object that has only  
> x-1, then you're in trouble because you've almost certainly stomped  
> on the header of the next object in memory. Sure, we could make the  
> basic routines check the bounds every time. Care to imagine the  
> performance impact?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Ornerythologists study bad tempered birds
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Philippe Marschall
In reply to this post by timrowledge
 
2007/5/22, tim Rowledge <[hidden email]>:

>
>
> On 22-May-07, at 7:23 AM, Damien Cassou wrote:
>
> >
> >
> > Much clearer :-) However, when methods access a non existing instance
> > variable, I think it should not crash the VM with a segfault.
>
> Lovely idea. But....
> Building bytecodes is just like using assembler; you can corrupt
> anything. Normally the compiler generates the correct, safe, code but
> if you're using some other tool that can be persuaded to pop the
> stack and save to x'th instance var ofan object that has only x-1,
> then you're in trouble because you've almost certainly stomped on the
> header of the next object in memory. Sure, we could make the basic
> routines check the bounds every time. Care to imagine the performance
> impact?

Java doesn't run exactly slow.

Cheers
Philippe

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Ornerythologists study bad tempered birds
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Andreas.Raab
 
Philippe Marschall wrote:

>> Lovely idea. But....
>> Building bytecodes is just like using assembler; you can corrupt
>> anything. Normally the compiler generates the correct, safe, code but
>> if you're using some other tool that can be persuaded to pop the
>> stack and save to x'th instance var ofan object that has only x-1,
>> then you're in trouble because you've almost certainly stomped on the
>> header of the next object in memory. Sure, we could make the basic
>> routines check the bounds every time. Care to imagine the performance
>> impact?
>
> Java doesn't run exactly slow.

Java isn't doing any runtime checks either. So what is your point?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Philippe Marschall
 
2007/5/22, Andreas Raab <[hidden email]>:

>
> Philippe Marschall wrote:
> >> Lovely idea. But....
> >> Building bytecodes is just like using assembler; you can corrupt
> >> anything. Normally the compiler generates the correct, safe, code but
> >> if you're using some other tool that can be persuaded to pop the
> >> stack and save to x'th instance var ofan object that has only x-1,
> >> then you're in trouble because you've almost certainly stomped on the
> >> header of the next object in memory. Sure, we could make the basic
> >> routines check the bounds every time. Care to imagine the performance
> >> impact?
> >
> > Java doesn't run exactly slow.
>
> Java isn't doing any runtime checks either. So what is your point?

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.

Cheers
Philippe

> Cheers,
>    - Andreas
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

timrowledge
 

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; [hidden email]; http://www.rowledge.org/tim
Gotta run, the cat's caught in the printer.


Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Philippe Marschall
 
2007/5/22, tim Rowledge <[hidden email]>:

>
>
> 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.

No, the VM checks the bytecodes when they are loaded. Sure you can
produce nonsense bytecodes like in this case but the VM will detect
that and not load them. Since methods are not first class they can not
be modifyed at runtime (I'm not sure they can in VW which has
immutable objects) you can not have corrupt bytecodes. It just can't
happen in Java even if you write a broken compiler.

Philippe

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Gotta run, the cat's caught in the printer.
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

johnmci
In reply to this post by timrowledge
 
Well a CPU is a bytecode reader in a sense too. When I was working on  
a 68K assembler interface for Ian's squeak compiler I was surprised  
to see
many instructions could be created that were not covered in the op  
code manual. Also I recall in the days of VirtualPC that team  
discovered certain
i386 machine sequences which would effectively crash the microcode,  
anyone recall what that "bug" was.  Certainly I remember patchs being  
loaded on
my linux box to prevent the problem from happening, once it had been  
leaked to the internet.


Lastly if this verify is so perfect, why the Java exploits I read  
about from time to time?

On May 22, 2007, at 11:03 AM, tim Rowledge wrote:

>
> 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; [hidden email]; http://www.rowledge.org/tim
> Gotta run, the cat's caught in the printer.
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Philippe Marschall
 
2007/5/22, John M McIntosh <[hidden email]>:

>
> Well a CPU is a bytecode reader in a sense too. When I was working on
> a 68K assembler interface for Ian's squeak compiler I was surprised
> to see
> many instructions could be created that were not covered in the op
> code manual. Also I recall in the days of VirtualPC that team
> discovered certain
> i386 machine sequences which would effectively crash the microcode,
> anyone recall what that "bug" was.  Certainly I remember patchs being
> loaded on
> my linux box to prevent the problem from happening, once it had been
> leaked to the internet.
>
>
> Lastly if this verify is so perfect, why the Java exploits I read
> about from time to time?

Sandbox violations. I think they have been around since Java exists. I
think most update releases fix one of them and you only hear about
them once they are fixed. I don't know if .Net is any better in this
area.

Cheers
Philippe

> On May 22, 2007, at 11:03 AM, tim Rowledge wrote:
>
> >
> > 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; [hidden email]; http://www.rowledge.org/tim
> > Gotta run, the cat's caught in the printer.
> >
> >
>
> --
> ========================================================================
> ===
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

K. K. Subramaniam
In reply to this post by johnmci
 
On Tuesday 22 May 2007 11:42 pm, John M McIntosh wrote:
> ....Also I recall in the days of VirtualPC that team
> discovered certain
> i386 machine sequences which would effectively crash the microcode,
> anyone recall what that "bug" was.  Certainly I remember patchs being
> loaded on
> my linux box to prevent the problem from happening, once it had been
> leaked to the internet.
Would that be the F00F bug in Pentium where the sequence "f0 0f c7 c8"
sequence would lockup the processor and require a reset?

Real scary one,
Subbu
Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

johnmci
 
yes

On May 22, 2007, at 8:02 PM, subbukk wrote:

>
> On Tuesday 22 May 2007 11:42 pm, John M McIntosh wrote:
>> ....Also I recall in the days of VirtualPC that team
>> discovered certain
>> i386 machine sequences which would effectively crash the microcode,
>> anyone recall what that "bug" was.  Certainly I remember patchs being
>> loaded on
>> my linux box to prevent the problem from happening, once it had been
>> leaked to the internet.
> Would that be the F00F bug in Pentium where the sequence "f0 0f c7 c8"
> sequence would lockup the processor and require a reset?
>
> Real scary one,
> Subbu

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

RE: Re: SegmentationFault in with OmniBrowser

Ted Neward
In reply to this post by timrowledge
 
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.

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: [hidden email] [mailto:vm-dev-
> [hidden email]] 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; [hidden email]; 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
 

Reply | Threaded
Open this post in threaded view
|

Re: Re: SegmentationFault in with OmniBrowser

Philippe Marschall
 
2007/5/23, Ted Neward <[hidden email]>:

>
> 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: [hidden email] [mailto:vm-dev-
> > [hidden email]] 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; [hidden email]; 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
>
>
>