SegmentationFault in with OmniBrowser

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

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

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

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

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

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

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

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

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

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

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

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