[ANN] 7061 = Squeak 3.9 final

>
> On 25-Sep-06, at 1:42 PM, Brad Fuller wrote:
>
>> stephane ducasse wrote:
>>>>> been an VM ignorant I cannot reply. Now I hope that this bug can
>>>>> be fixed for 3.9 VMs
>>>>> It seems to me that from an image perspective we can safely
>>>>> release the image.
>>>>> Now we should also move, so that people migrate their code on 3.9
>>>>> and that we start
>>>>> on 3.10 :)
>>>> Thanks for your comment, Stef. That seems reasonable. However, are
>>>> you sure that it's a VM issue? The VM crashes, but can it not be an
>>>> issue from higher up?
>>>
>>> Of course it can. But what can we do? do we have reproduceable bugs.
>>> I do not think so.
>> The code is in the mantis defect that is 100% reproducible on my PC.
>> I think it's easy to duplicate or make other PCs crash.
>>
>>> So we can stop 3.9 and postpone it but
>>> I'm pretty sure it will not help.
>> I think what you are saying is that 3.9 should be pushed forward
>> because there are few people to look at this problem. If this is the
>> case, a couple of comments to that:
>
> It doesn't affect my G5 mac so far. I have to say, 16 million float
> additions in 61 mS is damn fast.
>
> It would be helpful if someone could build a PC vm with a small change
> in the code that prints the callstack after a problem like this so
> that it doesn't cast the context address to a signed value before
> printing it. I'm puzzled by the apparently large jump to
> -2128068388 HandMorph>handleEvent:
> -2128068768 MouseOverHandler>processMouseOver:
> from
> 2032428416 HandMorph>handleEvent:
> 2032428116 HandMorph>processEvents
>
> -2128068768 is 0x81283F60 and 2032428416 is 0x79246580; that's a bit
> more of a difference than the usual 92 byte increment as we build the
> stack sending messages. I don't see anything very odd about the code
> in HandMorph>handleEvent: that would lead me to expect any message
> sending funny business.
>
> In the function printCallStackOf() that you should find in interp.c,
> try changing
> /* end findSelectorOfMethod:forReceiver: */;
>         printNum(ctxt);
>         print(" ");
>         if (!(ctxt == home)) {
> to
> /* end findSelectorOfMethod:forReceiver: */;
>         printf("%X", ctxt);
>         print(" ");
>         if (!(ctxt == home)) {
>
> and see if it can give us the stack in hex.

> On 2006 September 26 04:23, Giovanni Corriga wrote:
> >
> > Ok, here's mine:
> >
> > [gcorriga@rincewind ~]$ squeak -version
> > 3.9-7 #1 Thu May 18 12:06:33 CEST 2006 gcc 4.1.0
> > Squeak3.9alpha of 4 July 2005 [latest update: #7021]
> > Linux rincewind 2.6.16-1.2111_FC5.stk16 #1 Mon May 8 10:49:23 EDT 2006
> > i686 i686 i386 GNU/Linux
> > default plugin location: /usr/lib/squeak/3.9-7/*.so
> >
> > could this be related to the use of gcc 4.x?
>
> I think Bert said in another reply, this problem is likely due to the kernel
> and/or memory over 2Gb. On this system (where it works) I have 1Gb memory and
> something like 2Gb swap, my kernel=vmlinuz-2.6.11.4-21.13 so I guess it makes
> sense it works here from memory perspectivenot sure about 2.6 kernel.
> Giovanni, do you have over 2GB?

> tim Rowledge wrote:
>>
>> It doesn't affect my G5 mac so far. I have to say, 16 million float
>> additions in 61 mS is damn fast.
>>
>> It would be helpful if someone could build a PC vm with a small
>> change in the code that prints the callstack after a problem like
>> this so that it doesn't cast the context address to a signed value
>> before printing it. I'm puzzled by the apparently large jump to
>> -2128068388 HandMorph>handleEvent:
>> -2128068768 MouseOverHandler>processMouseOver:
>> from
>> 2032428416 HandMorph>handleEvent:
>> 2032428116 HandMorph>processEvents
>>
>> -2128068768 is 0x81283F60 and 2032428416 is 0x79246580; that's a bit
>> more of a difference than the usual 92 byte increment as we build the
>> stack sending messages. I don't see anything very odd about the code
>> in HandMorph>handleEvent: that would lead me to expect any message
>> sending funny business.
>>
>> In the function printCallStackOf() that you should find in interp.c,
>> try changing
>> /* end findSelectorOfMethod:forReceiver: */;
>>         printNum(ctxt);
>>         print(" ");
>>         if (!(ctxt == home)) {
>> to
>> /* end findSelectorOfMethod:forReceiver: */;
>>         printf("%X", ctxt);
>>         print(" ");
>>         if (!(ctxt == home)) {
>>
>> and see if it can give us the stack in hex.
> [bfuller@ives bld]$ ./squeak
> /home/bfuller/projects/squeak/images/Squeak3.9g-7060.image
>
> sweep failed to find exact end of memory
>
> 813821F4 Morph>hasDropShadow
> 81381ABC Morph>fullDrawOn:
> 81381A60 Canvas>fullDraw:
> 81381A04 Canvas>fullDrawMorph:
> 81380A7C [] in Morph>drawSubmorphsOn:
> 813809C4 SequenceableCollection>reverseDo:
> 813808B0 [] in Morph>drawSubmorphsOn:
> 81380570 Morph>drawSubmorphsOn:
> 81373030 [] in Morph>fullDrawOn:
> 81372F1C FormCanvas>roundCornersOf:in:during:
> 81372DC8 Canvas>roundCornersOf:during:
> 8137146C Morph>fullDrawOn:
> 81371410 Canvas>fullDraw:
> 81371358 Canvas>fullDrawMorph:
> 813710EC [] in WorldState>drawWorld:submorphs:invalidAreasOn:
> 81370B94 Rectangle>allAreasOutsideList:startingAt:do:
> 81370A3C Rectangle>allAreasOutsideList:do:
> 81370FF0 [] in WorldState>drawWorld:submorphs:invalidAreasOn:
> 813709E0 SequenceableCollection>do:
> 81370A98 WorldState>drawWorld:submorphs:invalidAreasOn:
> 81370814 [] in WorldState>displayWorld:submorphs:
> 813706A4 FormCanvas>roundCornersOf:in:during:
> 81370648 Canvas>roundCornersOf:during:
> 81370534 WorldState>displayWorld:submorphs:
> 813703C4 PasteUpMorph>privateOuterDisplayWorld
> 813702D8 PasteUpMorph>displayWorld
> 81370420 [] in WorldState>displayWorldSafely:
> 8137027C BlockContext>on:do:
> 81370220 BlockContext>ifError:
> 813701C4 WorldState>displayWorldSafely:
> 79332CA0 WorldState>doOneCycleNowFor:
> 79332C44 WorldState>doOneCycleFor:
> 79332BE8 WorldState>doOneSubCycleFor:
> 79332B8C PasteUpMorph>doOneSubCycle
> 7932E268 MenuMorph>invokeModalAt:in:allowKeyboard:
> 7932E20C MenuMorph>invokeModal:
> 7932E09C MenuMorph>invokeModal
> 7932C6E0 PluggableTextMorph>yellowButtonActivity:
> 7932C684 TextMorphForEditView>mouseDown:
> 7932C628 Morph>handleMouseDown:
> 7932C5CC MouseButtonEvent>sentTo:
> 7932C570 Morph>handleEvent:
> 7932C508 MorphicEventDispatcher>dispatchMouseDown:with:
> 7932C484 MorphicEventDispatcher>dispatchEvent:with:
> 7932C428 Morph>processEvent:using:
> 7932C3A4 MorphicEventDispatcher>dispatchMouseDown:with:
> 7932C320 MorphicEventDispatcher>dispatchEvent:with:
> 7932C2C4 Morph>processEvent:using:
> 7932C268 MorphicEventDispatcher>dispatchMouseDown:with:
> 7932C20C MorphicEventDispatcher>dispatchEvent:with:
> 7932C1B0 Morph>processEvent:using:
> 7932C12C MorphicEventDispatcher>dispatchMouseDown:with:
> 7932C0D0 MorphicEventDispatcher>dispatchEvent:with:
> 7932C074 Morph>processEvent:using:
> 7932C018 MorphicEventDispatcher>dispatchMouseDown:with:
> 7932BFBC MorphicEventDispatcher>dispatchEvent:with:
> 7932BF50 Morph>processEvent:using:
> 7932BEF4 PasteUpMorph>processEvent:using:
> 7932BE3C Morph>processEvent:
> 7932BDE0 HandMorph>sendEvent:focus:clear:
> 7932BD84 HandMorph>sendMouseEvent:
> 7932BCF4 HandMorph>handleEvent:
> 7932BC18 HandMorph>processEvents
> 7932BC74 [] in WorldState>doOneCycleNowFor:
> 7932BBBC SequenceableCollection>do:
> 7932BB60 WorldState>handsDo:
> 7932BB04 WorldState>doOneCycleNowFor:
> 7932BAA8 WorldState>doOneCycleFor:
> 7932BA4C PasteUpMorph>doOneCycle
> 78F82E24 [] in >spawnNewProcess
> 78F82EDC [] in BlockContext>newProcess
>
> [bfuller@ives bld]$ ./squeak -version
> 3.9-8 #6 Tue Sep 26 15:01:19 PDT 2006 gcc 4.1.1
> Squeak3.9alpha of 4 July 2005 [latest update: #7021]
> Linux ives 2.6.16-1.2080.16.rrt.rhfc5.ccrma #1 PREEMPT Tue Jul 25
> 15:06:37 EDT 2006 i686 i686 i386 GNU/Linux
> default plugin location: /usr/local/lib/squeak/3.9-8/*.so
>
>
>

>>
>> and see if it can give us the stack in hex.
> [bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/
> Squeak3.9g-7060.image
>
> sweep failed to find exact end of memory
>
> 813821F4 Morph>hasDropShadow
> 81381ABC Morph>fullDrawOn:
> 81381A60 Canvas>fullDraw:
> 81381A04 Canvas>fullDrawMorph:

>> There is a SystemOrganization>fileOut method that appears to work
>> (although for some reason making a file 'SystemOrganization.
>> 1.st.st' !) and maybe that was hooked up at some point.
>
> Also it is very important to properly log class renames. There is
> something broken in this area as well.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>

> [hidden email] writes:
> > Yes, this is an unfortunate situation that I need to go through. The
> > problem is that after I introduced the server side cache and SHA
> > checksumming apparently lots of releases either were non-available at
> > the time I initially populated the cache (which lead to crap files in
> > the server cache, and to make things worse - crappy checksums!) OR have
> > been unavailable when releases have been registered. I think.
>
> I run into this as well if SqueakMap downloads while the network is
> unavailable.  It saves to the file an error message, and so of course
> its checksum is wrong.  So, the tool could be more careful about
> checking that the HTTP request worked, before saving the file.

> [hidden email] writes:
> > > I also ran into this when I tried to update the URL of a released
> > > SqueakMap version.  Maybe this is more in the line of what you discuss
> > > with bad cached information on the server.  I ended up bumping the
> > > version number even though the actual file content had not changed.
>
>
> [hidden email] writes:
> > IIRC the current logic is that when the URL of a release is modified -
> > it will repopulate the server side cache and update the checksum,
> > Was that what you tried to do? Because I thought that worked.
>
> Before reading this thread, I did not know there was a server-side
> cache at all!
>
> Anyway, yes, I tried to update the card for Universes version 9 to
> point to SqueakSource's new host name (i.e., swapping the unibe.ch
> name for squeaksource.com).  For whatever reason, I could not get it
> to work, so I instead posted a version 9b.
>
> I am not sure a separate 9b card is a bad idea, anyway.  The version 9
> card is already published, and, philosophically, mutating a published
> card seems a little weird.

>
> On 26-Sep-06, at 3:11 PM, Brad Fuller wrote:
>
>>>
>>> and see if it can give us the stack in hex.
>> [bfuller@ives bld]$ ./squeak /home/bfuller/projects/squeak/images/
>> Squeak3.9g-7060.image
>>
>> sweep failed to find exact end of memory
>>
>> 813821F4 Morph>hasDropShadow
>> 81381ABC Morph>fullDrawOn:
>> 81381A60 Canvas>fullDraw:
>> 81381A04 Canvas>fullDrawMorph:
>
> Thanks Brad. That 128-and-a-bit Mb jump is definitely puzzling.  
> That's a lot of allocations between the start of doOneCycleNowFor:  
> and displayWorldSafely:

>
> Am 27.09.2006 um 07:33 schrieb Lukas Renggli:
>
>>> There is a SystemOrganization>fileOut method that appears to work
>>> (although for some reason making a file 'SystemOrganization.
>>> 1.st.st' !) and maybe that was hooked up at some point.
>>
>> Also it is very important to properly log class renames. There is
>> something broken in this area as well.
>
> ... as well as when moving a method from one category to an other -  
> if this moves a method from one package to another, only one MC  
> package is marked dirty. Also, IIRC, renaming a method category  
> does not trigger any notification.
>
> - Bert -
>
>