Envy 1.43->Envy 3.01 core dumps 
Author Message
 Envy 1.43->Envy 3.01 core dumps

Hi,

I'm moving an old Smalltalk application from a VW1.0/Envy 1.43 image to
VW2.5/Envy 3.01 image and am having some problems with the compiled byte
codes stored by Envy e.g. the is a class extension on Integer:

Integer>>padWithZeros: size
        | tmp pad |
        tmp := self asString.
        (pad := size - tmp size) > 0
                ifTrue: [tmp := (String new: pad withAll: $0) , tmp].
        ^tmp

If I run the following the image core dumps:

"18 padWithZeros: 2"

However if I reaccept the method it does what it should! If I inspect
the byte codes this is what I get:

Before:

normal CompiledMethod numArgs=1 numTemps=2 frameSize=12

literals: ({String} #new:withAll: )

1 <44> push self
2 <CE 6E> non-immediate send asString
4 <4D> store local 1; pop
5 <10> push local 0
6 <11> push local 1
...

After:

normal CompiledMethod numArgs=1 numTemps=2 frameSize=12

literals: ({String} #new:withAll: )

1 <44> push self
2 <F0 6E> send asString
4 <4D> store local 1; pop
5 <10> push local 0
6 <11> push local 1
...

Note that the 2nd byte code has changed from "<CE 6E> non-immediate send
asString" to "<F0 6E> send asString"

So what do I need to do to get Envy to recompile all the methods
correctly for the VW2.5 VM ?

Thanks,

Reuben

--
Reuben Wells, CW/8, 25 Cabot Square, Canary Wharf, London, E14 4QA



Sat, 11 Sep 1999 03:00:00 GMT  
 Envy 1.43->Envy 3.01 core dumps

Quote:

> Hi,

> I'm moving an old Smalltalk application from a VW1.0/Envy 1.43 image to
> VW2.5/Envy 3.01 image and am having some problems with the compiled byte
> codes stored by Envy e.g. the is a class extension on Integer:

> Integer>>padWithZeros: size
>         | tmp pad |
>         tmp := self asString.
>         (pad := size - tmp size) > 0
>                 ifTrue: [tmp := (String new: pad withAll: $0) , tmp].
>         ^tmp

> If I run the following the image core dumps:

> "18 padWithZeros: 2"

> However if I reaccept the method it does what it should! If I inspect
> the byte codes this is what I get:

> Before:
> 1 <44> push self
> 2 <CE 6E> non-immediate send asString
> 4 <4D> store local 1; pop
> 5 <10> push local 0
> 6 <11> push local 1
> ...

> After:
> 1 <44> push self
> 2 <F0 6E> send asString
> 4 <4D> store local 1; pop
> 5 <10> push local 0
> 6 <11> push local 1
> ...

> Note that the 2nd byte code has changed from "<CE 6E> non-immediate send
> asString" to "<F0 6E> send asString"

Since the receiver is an immediate (the SmallInteger 18) doing
a non-immediate send to it causes the engine to attempt to
indirect though an invalid address.  You can find a full explanation

You'll find it easily by going to www.altavista.com and searching
Usenet for "Eliot & Linda".  The post's title is
    Re: Send bytecodes in VW2.51 - help needed

Quote:
> So what do I need to do to get Envy to recompile all the methods
> correctly for the VW2.5 VM ?

You only need to recompile all methods in SmallInteger, Character
and their superclasses (see the post for why).  Something like

        (SmallInteger withAllSuperclasses,
        Character withAllSuperclasses) asSet do: [:class|
                class selectors do: [:s|
                        clas recompile: s from: class]]

should work.  I'm sorry I don't know how to make this happen
by default on loading, but that would be what I'd try and arrange.
I.e. if Envy loads a method that is inherited by SmallInteger
or Character then it would be recompiled from source when loaded.

Excuse this nonsense at the bottom but my gateway (?) refuses
to post anything that includes more text than it adds.  Annoying.

_______________,,,^..^,,,_______________
Eliot & Linda



Sat, 11 Sep 1999 03:00:00 GMT  
 Envy 1.43->Envy 3.01 core dumps

Quote:

> I'm moving an old Smalltalk application from a VW1.0/Envy 1.43 image to
> VW2.5/Envy 3.01 image...
> If I run the following the image core dumps:

There is a two-part ENVY patch that deals with this. (I think it is 960411
or 960429.) One part of the patch is an expression that you evaluate. It
traverses your repository and removes pre-compiled code and re-compiles all
methods that extend Object, Character or SmallInteger.

You really want to use this patch and do it right in the repository. If you
simply re-compile in your image (by using #recompile:from:, for example),
re-loading from ENVY will re-load the bad methods, and you'll have the
problem all over again. If you force a source code compile (by putting a
space in every method, for example), you've really messed up your
tracability, and will have a devil of a time re-integrating with the next
release, because everything will show up as a change.


: Bytesmiths <http://www.bytesmiths.com>



Sat, 11 Sep 1999 03:00:00 GMT  
 Envy 1.43->Envy 3.01 core dumps

Quote:

> Hi,

> I'm moving an old Smalltalk application from a VW1.0/Envy 1.43 image to
> VW2.5/Envy 3.01 image and am having some problems with the compiled byte
> codes stored by Envy e.g. the is a class extension on Integer:

> Integer>>padWithZeros: size
>    | tmp pad |
>    tmp := self asString.
>    (pad := size - tmp size) > 0
>            ifTrue: [tmp := (String new: pad withAll: $0) , tmp].
>    ^tmp

> If I run the following the image core dumps:

> "18 padWithZeros: 2"

There is a bug in Envy301 (or VW 2.5, one or the other) that affected
some methods in Integer and String.  The fix (you already found) is
to recompile the methods.  We had a similar problem here with
an extension to Integer.  There doesn't seem to be any hard and fast
way to determine what is broken and what isn't except to test
the methods.  Safest thing to do is re-accept everything that's an extension
to Integer (and it's subclasses).

dave.

--
-------------------------------------------------------
David Rubie                           "Your brother's dead.
Macquarie Bank Ltd.                    Keep dancing!"

                                        "Never Say Never Again").



Sun, 12 Sep 1999 03:00:00 GMT  
 Envy 1.43->Envy 3.01 core dumps

FYI...
Below is part of the text from the "read.me" that comes with the
960209 ENVY patch.

ftp://ftp.oti.com/pub/patches/developer/r3.01/

Keith Link

Quote:
> Documentation for Patch 951201
> ==============================

> This patch corrects the generation of bytecodes when methods
> written in previous releases of ENVY/Developer (before R3.01)
> are loaded into R3.01.

> Patch 951201 fixes this problem report:

>     1DJ5JVK: Problem with export from old E/D to E/D R3.01

>     When loading methods from an earlier version of ENVY/Developer
>     into R3.01, the bytecodes generated may be incorrect and
>     could crash the VM.  If your application extends any of the
>     following classes, you may get incorrect bytecodes in your
>     library:  SmallInteger, Character, Object, Magnitude,
>     ArithmeticValue, Number, Integer.

>     If you have changed the superclass of any of these classes,
>     this patch will not fix the problem and you should contact OTI
>     to obtain a different patch.

>     The problem does NOT affect methods that have been compiled
>     in an R3.01 image - only methods that have been compiled in
>     previous releases of ENVY/Developer.

> This patch was originally loaded in two steps:
>     -  to remove from the library the bytecodes for the methods
>        that were compiled incorrectly in the above classes.
>     -  to change the way the bytecodes are generated.

> This patch was integrated into Patch 960209.  The steps above no
> longer need to be executed unless you load additional methods
> that extend the classes noted above from an earlier version of
> ENVY/Developer.  If this is true, you need to execute part b of
> the 951201 Patch, which is given here:



Sun, 12 Sep 1999 03:00:00 GMT  
 Envy 1.43->Envy 3.01 core dumps

Quote:

>> I'm moving an old Smalltalk application from a VW1.0/Envy 1.43 image to
>> VW2.5/Envy 3.01 image and am having some problems with the compiled byte
>> codes stored by Envy e.g. the is a class extension on Integer:

You need to apply the Envy 3.01 patches from OTI. I believe in particular you
need 960209. This is extremely important.

--
Alan Knight                     | The Object People

613.225.8812(v) 613.225.5943(f) | http://www.objectpeople.com

 Inheritence is an implementation issue.
 If you pay me enough, I'll subclass Ellipse off of Employee
    - Mike Klein



Sun, 12 Sep 1999 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Envy 1.43 -> 3.01, DLL/C Connect problem

2. VW-Envy-Smalltalk Broker Core Dump with type any

3. Envy R1.43 under Solaris

4. VisualWorks 2.5.1 witn Envy 3.01 ?

5. Usage of Browsers in VW/ENVY 3.01

6. Envy 3.01 documentation error

7. Arbor Probe for VisualWorks 2.5.2 (ENVY 3.01)

8. 3.0 + Envy -> 5i.X + Envy

9. HELP: Color Browser in Envy 3.01

10. Envy 3.01 Corruption

11. Envy 3.01/VW 2.5 on NT 4.0

12. Envy 3.01 on Windows NT 4.0(1381)?

 

 
Powered by phpBB® Forum Software