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 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
Hi Andreas,
2007/5/19, Andreas Raab andreas.raab@gmx.de:
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?
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
2007/5/22, Lukas Renggli renggli@gmail.com:
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.
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; tim@rowledge.org; http://www.rowledge.org/tim Ornerythologists study bad tempered birds
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; tim@rowledge.org; http://www.rowledge.org/tim Ornerythologists study bad tempered birds
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
2007/5/22, tim Rowledge tim@rowledge.org:
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; tim@rowledge.org; http://www.rowledge.org/tim Ornerythologists study bad tempered birds
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
2007/5/22, Andreas Raab andreas.raab@gmx.de:
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
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@rowledge.org; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer.
2007/5/22, tim Rowledge tim@rowledge.org:
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; tim@rowledge.org; 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; tim@rowledge.org; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
2007/5/22, John M McIntosh johnmci@smalltalkconsulting.com:
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; tim@rowledge.org; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer.
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 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
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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.
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@lists.squeakfoundation.org [mailto:vm-dev- bounces@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@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
2007/5/23, Ted Neward ted@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@lists.squeakfoundation.org [mailto:vm-dev- bounces@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@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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Damien Cassou -
John M McIntosh -
Lukas Renggli -
Philippe Marschall -
subbukk -
Ted Neward -
tim Rowledge