Image Crash in VA4.02 
Author Message
 Image Crash in VA4.02

I am experiencing some very strange behaviour with VA4.02 on Windows NT.  If
I do the following sequence of things my image cashes,

1.  Define a subclass of Object and give it a single instance variable.
2.  Define a getter for that instance variable.
3.  Delete the instance variable from the class definition.  When the class
is recompiled the error in the getter is detected and a message is output to
the Transcript saying that the method has been deleted.  However, the class
browser indicates that the method is still there ?!?.
4.  Evaluate 'YourClass new yourGetter' a few times.  On about the third go
the image crashes.

I assume the image is crashing because the getter is providing access to
memory which it shouldn't, but why does VisualAge allow this to happen -
surely the method should be removed from the class to protect people from
themselves?  Does anyone else get this problem?

Merry Christmas

Glenn



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02

Quote:

>I assume the image is crashing because the getter is providing access to
>memory which it shouldn't, but why does VisualAge allow this to happen -
>surely the method should be removed from the class to protect people from
>themselves?

Probably.. strangely enough, I get rather unusual behavior doing the same
thing under Visual Smalltalk.

Ian

----------------------------------------------------------------------------

----------------------------------------------------------------------------
                 http://www.oneaccordinc.com/ian/home.html



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02


Quote:
> I am experiencing some very strange behaviour with VA4.02 on Windows NT.
If
> I do the following sequence of things my image cashes,

> 1.  Define a subclass of Object and give it a single instance variable.
> 2.  Define a getter for that instance variable.
> 3.  Delete the instance variable from the class definition.  When the
class
> is recompiled the error in the getter is detected and a message is output
to
> the Transcript saying that the method has been deleted.  However, the
class
> browser indicates that the method is still there ?!?.

The message to the Transcript is your notification to do something about
the method. Either delete it or re-write it. The method is not
automatically deleted to aid in refactoring. If every time you changed a
value from an inst var to a computed value, the system deleted all the
methods referencing the former inst var, you would have a very difficult
time refactoring the code.

Quote:
> 4.  Evaluate 'YourClass new yourGetter' a few times.  On about the third
go
> the image crashes.

That, of course, should not happen and should be reported to IBM as a bug.
OTOH, why are you doing this? Just to see if it will crash? Try "Smalltalk
become: nil" and see what happens. Should that be a bug too? Smalltalk is a
highly malleable system. There is a presumption of the part of the
implementors that you, as developer, will use it the "right" way. VisualAge
writes numerous warning and errors to the Transcript. It is your
responsibility to either deal with them or risk the consequences (of
course, a walkback in the above case would be a better result than a
crash).

Quote:
> I assume the image is crashing because the getter is providing access to
> memory which it shouldn't, but why does VisualAge allow this to happen -
> surely the method should be removed from the class to protect people from
> themselves?  

The method should not be removed. That should be a decision left to the
developer. More often then not, you don't want the method deleted and would
prefer to re-write it.

Quote:
> Does anyone else get this problem?

Not really. When refactoring, I always make sure to delete or re-write any
of the affected methods. While you can discern the list of affected methods
from the Transcript warnings, the easiest thing to do is get a list of all
methods accessing the inst var *before* you delete the inst var. Then you
can use the methods browser to dispose of or correct the offending methods.

-Eric Clayberg
Vice President
Instantiations, Inc., Smalltalk Systems Division


 http://www.smalltalksystems.com
 http://www.instantiations.com

 GO SMALLTALK!



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02

Quote:



> > I am experiencing some very strange behaviour with VA4.02 on Windows NT.
> If
> > I do the following sequence of things my image cashes,

> > 1.  Define a subclass of Object and give it a single instance variable.
> > 2.  Define a getter for that instance variable.
> > 3.  Delete the instance variable from the class definition.  When the
> class
> > is recompiled the error in the getter is detected and a message is output
> to
> > the Transcript saying that the method has been deleted.  However, the
> class
> > browser indicates that the method is still there ?!?.

> The message to the Transcript is your notification to do something about
> the method. Either delete it or re-write it. The method is not
> automatically deleted to aid in refactoring. If every time you changed a
> value from an inst var to a computed value, the system deleted all the
> methods referencing the former inst var, you would have a very difficult
> time refactoring the code.

[egg-sucking alert]

But leaving the system in such an unsafe state is hardly satisfactory.
Smalltalks derived from Smalltralk-80 (i.e. VisualWorks & Squeak) do
something safer.  They recompile all methods that refer to the deleted
instance variable so that they refer to an Undeclared variable of the
same name of the instance variable.  Hence the system is still gc-safe,
the code is still available for refactoring, and all references to the
undeclared variable can be quickly found via a suitable browsing
command, typically in the Undeclared inspector.

_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace Aspect, ObjectShare



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02

Quote:

> In response to a question I raised about a sequence of actions that caused
> an image crash Eric Clayberg kindly replied with the observation that:
> Whilst I appreciate Mr. Clayberg's response I think it serves to illustrate
> one of the main difficulties faced by the Smalltalk language.  To suggest
> that I would be doing this to "see if it would crash" makes me sound like I
> have nothing better to do with my time than try and find ways to undermine
> Smalltalks reputation.  If you hold the development environment in such high
> regard that you are not prepared to criticise it when it displays an obvious
> flaw then you will inhibit its evolution.  I do not accept this behaviour is
> a characteristic of a "malleable system".

Note that the problem you had with VisualAge does not exist with VisualWorks;
you'll get a nil
back from the message send.  The variable now exists in Undeclared (a system
dictionary).  This
is indicative of a development issue to be resolved, but it does not cause
abject failure of the system.

Quote:

> I think the problem I have described is one that can come about through the
> natural course of development whereas "Smalltalk become: nil" is not.

<snip>

Yep.  In fact, I've done it more than once myself.  Perhaps a 'perfect'
developer wouldn't,
but I'm not in that state of grace ;-)

Quote:

> The problem I now have is that my image may be littered with references to
> deleted instance variables.  I accept that had I done things properly I
> would not have created this problem but given that Smalltalk is malleable
> enough to allow me to create this mess it must be malleable enough to give
> me a way out.  How can I locate all methods in an image that refer to a
> removed instrance variable?

In VisualWorks, check the Dictionary Undeclared.  You'll see all such variable
references
have migrated there.  You can find the refs to them (methods), and go about
cleaning them up.
You don't have to be perfect to use Smalltalk; in fact, it's a great system for
doing exploratory programming.
Some implementations handle such issues better than others; Eliot Miranda went
into depth on
this point in an earlier post.

Quote:

> Happy New Year

> Glenn Jones

--
Talk Small and Carry a Big Class Library

<Opinions expressed are not necessarily those of ObjectShare>

  jamesr.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02
In response to a question I raised about a sequence of actions that caused
an image crash Eric Clayberg kindly replied with the observation that:

Quote:
>That, of course, should not happen and should be reported to IBM as a bug.
>OTOH, why are you doing this? Just to see if it will crash? Try "Smalltalk
>become: nil" and see what happens. Should that be a bug too? Smalltalk is a
>highly malleable system. There is a presumption of the part of the
>implementors that you, as developer, will use it the "right" way. VisualAge
>writes numerous warning and errors to the Transcript. It is your
>responsibility to either deal with them or risk the consequences (of
>course, a walkback in the above case would be a better result than a
>crash).

Whilst I appreciate Mr. Clayberg's response I think it serves to illustrate
one of the main difficulties faced by the Smalltalk language.  To suggest
that I would be doing this to "see if it would crash" makes me sound like I
have nothing better to do with my time than try and find ways to undermine
Smalltalks reputation.  If you hold the development environment in such high
regard that you are not prepared to criticise it when it displays an obvious
flaw then you will inhibit its evolution.  I do not accept this behaviour is
a characteristic of a "malleable system".

I think the problem I have described is one that can come about through the
natural course of development whereas "Smalltalk become: nil" is not.  A
good development environment should not permit the introduction of bugs that
cause it to crash in the natural course of development.  As long as the
Smalltalk community continues to alienate developers by telling them that
Smalltalk is fine so long as you do it the "right" way then it will never
gain popular appeal.

The problem I now have is that my image may be littered with references to
deleted instance variables.  I accept that had I done things properly I
would not have created this problem but given that Smalltalk is malleable
enough to allow me to create this mess it must be malleable enough to give
me a way out.  How can I locate all methods in an image that refer to a
removed instrance variable?

Happy New Year

Glenn Jones



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02


Quote:

> >That, of course, should not happen and should be reported to IBM as a
bug.
> >OTOH, why are you doing this? Just to see if it will crash? Try
"Smalltalk
> >become: nil" and see what happens. Should that be a bug too? Smalltalk
is a
> >highly malleable system. There is a presumption of the part of the
> >implementors that you, as developer, will use it the "right" way.
VisualAge
> >writes numerous warning and errors to the Transcript. It is your
> >responsibility to either deal with them or risk the consequences (of
> >course, a walkback in the above case would be a better result than a
> >crash).

> Whilst I appreciate Mr. Clayberg's response I think it serves to
illustrate
> one of the main difficulties faced by the Smalltalk language.  To suggest
> that I would be doing this to "see if it would crash" makes me sound like
I
> have nothing better to do with my time than try and find ways to
undermine
> Smalltalks reputation.

Not at all. It just seemed like a very contrived test. I have been working
with VisualAge for going on five years now and Smalltalk for twice that
long and I have never run into a system crash like that (walkbacks yes, but
never a crash). I've never even seen it raised an issue in regard to
VisualAge (which is likely why it was never fixed), so I consider it to be
a very obscure bug (although it is definitely a bug as I stated above). I
guess I honestly see this as a bug exposed by somewhat sloppy programming
practices (sorry). VisualAge provides numerous warnings about dozens of
conditions. Sometimes folks get desensitized to them and ignore them.
That's how you get into trouble.

Quote:
> If you hold the development environment in such high
> regard that you are not prepared to criticise it when it displays an
obvious
> flaw then you will inhibit its evolution.

Note that I did not do this. The first thing I said was that "should not
happen and should be reported to IBM as a bug." Don't get me wrong, this is
definitely a bug that IBM should fix. It should even be a pretty easy bug
to fix.

Quote:
> I do not accept this behaviour is
> a characteristic of a "malleable system".

It is definitely a side effect of the above. That does not excuse the fact
that it is a valid bug.

Quote:
> I think the problem I have described is one that can come about through
the
> natural course of development whereas "Smalltalk become: nil" is not.

I disagree. I have blown up my system dozens (hundreds?) of times by
"becoming nil" on the wrong thing. I have blown it up making bogus DLL
calls many hundreds of times. I have run into walkbacks due to the
condition you described very, very rarely (it's probably been a couple of
years since the last time). I have never had the system crash. BTW, just as
an aside, VA only seems to crash if the inst var access was to a slot that
no longer exists (e.g., the number of inst vars was reduced and the method
references a slot beyond that last valid slot).

Quote:
> A good development environment should not permit the introduction of
> bugs that cause it to crash in the natural course of development.

In theory I agree with you. Certainly in regard to this specific bug, I
agree. In practice, however, this is not very easy to accomplish in
Smalltalk. Since all Smalltalk systems that I know of allow you to modify
existing code (except ObjectShare's experimental FireWall system), all of
them are susceptible to development induced crashes. Modifying base image
GUI code, for example, is an easy way to trash your system if you aren't
careful. Are Smalltalk systems not "good" because they allow you to modify
the development environment itself and kill it in the process if you aren't
careful? I don't think so.

Quote:
> As long as the Smalltalk community continues to alienate developers
> by telling them that Smalltalk is fine so long as you do it the "right"
> way then it will never gain popular appeal.

I think you missed the point of my original response. In addition to
reporting the obvious bug, you need to be a bit more aware of any warnings
or errors that VisualAge tells you about.

Quote:
> The problem I now have is that my image may be littered with references
to
> deleted instance variables.

I sure hope not.

Quote:
> I accept that had I done things properly I
> would not have created this problem but given that Smalltalk is malleable
> enough to allow me to create this mess it must be malleable enough to
give
> me a way out.  How can I locate all methods in an image that refer to a
> removed instrance variable?

There are likely quite a few ways you could determine this. An easy way
might be to force a recompile of all of your classes (or just the ones you
are worried about). The same errors that were written to the Transcript the
first time, should appear again. Other approaches would include cycling
through all of your compiled methods and asking for their parse trees. Any
that returned an error would be suspect. Since, in addition to flagging the
original error in the Transcript, VA also removes the broken methods from
their associated class definitions in the library, another approach would
be to cycle through the compiled methods and look for those that are no
longer properly attached to their respective classes. You could also
compare the method dictionaries of your classes with the class definitions
in the library to look for invalid methods{*filter*} out in your method
dictionaries.

-Eric Clayberg
Vice President
Instantiations, Inc., Smalltalk Systems Division


  http://www.*-*-*.com/
  http://www.*-*-*.com/

 GO SMALLTALK!



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02
I am trying to work out how to locate all methods in an image which refer to
deleted instance variables.  There have been a few suggestions so far which
are much appreciated and are listed below.  Has anyone actually tried to do
any of these things in VisualAge 4.02 and if so can they share with me the
specific details of what is involved (ie. method and class names please).

1.  Recompile all classes.
2.  Cycling through all compiled methods and ask for their parse trees.
3.  Cycle through compiled methods and look for those that are no longer
properly attached to their respective classes.
4.  Compare method dictionaries of classes with the class definitions in the
library and look for invalid methods{*filter*} out in the method dictionaries.

Recompiling all classes sounds the easiest to me so if anyone can tell me
how to do that or provide details on how to implement any of the above
procedures it would be much appreciated.  I would also be grateful if anyone
can tell me what the procedure is for bringing a bug to the attention of
IBM.

Thanks,

Glenn Jones



Wed, 18 Jun 1902 08:00:00 GMT  
 Image Crash in VA4.02
Perhaps Eric got some bad eggnog over the holidays -- he's not usually so
cranky <gr>.  I'll agree with his "Smalltalk become: nil" example, but not
his response to this problem.

The computer and, by extension, Smalltalk are tools that are supposed to
make our lives easier, not harder (don't get me started on whether this is
reality or fiction).  We are all human beings who make mistakes on occasion.
Your problem is not even really a mistake -- rather it is just VA ST
misbehavior at a transition point from one correct image state to another.
What you've observed is definately NOT the way VA ST should behave in this
situation.  Please submit a problem report.

John O'Keefe
IBM VisualAge Smalltalk Enterprise Team

Quote:

>In response to a question I raised about a sequence of actions that caused
>an image crash Eric Clayberg kindly replied with the observation that:

>>That, of course, should not happen and should be reported to IBM as a bug.
>>OTOH, why are you doing this? Just to see if it will crash? Try "Smalltalk
>>become: nil" and see what happens. Should that be a bug too? Smalltalk is
a
>>highly malleable system. There is a presumption of the part of the
>>implementors that you, as developer, will use it the "right" way.
VisualAge
>>writes numerous warning and errors to the Transcript. It is your
>>responsibility to either deal with them or risk the consequences (of
>>course, a walkback in the above case would be a better result than a
>>crash).

>Whilst I appreciate Mr. Clayberg's response I think it serves to illustrate
>one of the main difficulties faced by the Smalltalk language.  To suggest
>that I would be doing this to "see if it would crash" makes me sound like I
>have nothing better to do with my time than try and find ways to undermine
>Smalltalks reputation.  If you hold the development environment in such
high
>regard that you are not prepared to criticise it when it displays an
obvious
>flaw then you will inhibit its evolution.  I do not accept this behaviour
is
>a characteristic of a "malleable system".

>I think the problem I have described is one that can come about through the
>natural course of development whereas "Smalltalk become: nil" is not.  A
>good development environment should not permit the introduction of bugs
that
>cause it to crash in the natural course of development.  As long as the
>Smalltalk community continues to alienate developers by telling them that
>Smalltalk is fine so long as you do it the "right" way then it will never
>gain popular appeal.

>The problem I now have is that my image may be littered with references to
>deleted instance variables.  I accept that had I done things properly I
>would not have created this problem but given that Smalltalk is malleable
>enough to allow me to create this mess it must be malleable enough to give
>me a way out.  How can I locate all methods in an image that refer to a
>removed instrance variable?

>Happy New Year

>Glenn Jones



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. help: packaging a headless image in VA4.02

2. VA4.02 Packetting Container Details how?

3. VA4.02 - Form swapping ( Subcanvases in VW )

4. NT & VA4.02 problems

5. Splash Screen on NT for VA4.02

6. PoolDictionary questions in [VA4.02]

7. VA4.02 docs in BookManager format?

8. Flakey VA4.02

9. Q: [VA4.02] Is there a way on taking the ICON off

10. Q: Take Icon (eye) off of the Window VA4.02

11. CFP Generators and Components (GCSE/SAIG'02) (Pittsburgh, 10/02)

12. CA-Clipper 5.2E 02/02

 

 
Powered by phpBB® Forum Software