Thanks, and my apologies for being so sensitive to this.
Ivan
-----Original Message----- From: Marcus Denker [mailto:marcus@ira.uka.de] Sent: Friday, June 13, 2003 9:38 AM To: The general-purpose Squeak developers list Subject: Re: Fun article
On Fri, Jun 13, 2003 at 09:32:12AM -0300, Ivan Tomek wrote:
Too bad they can't spell Smalltalk right.
Oh, horrors of all horrors. ;-)
How could that happen? I just tried to fix it, and, in my local PersonalWiki this is allready corrected. So I synced this with the website. No change. Hmm. The problem seems to be MacOS: the only Unix-Filesystem that is not case-sesitive. I guess I fixed the typo as soon as I saved the first wrong version (they are both dated the same), only the html-conversion scripts did not write the new file (it was allready there...)
http://www.ira.uka.de/~marcus/_The_Early_History_of_Smalltalk_.html
Marcus
-- Marcus Denker marcus@ira.uka.de -- Squeak! http://squeak.de
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Hi mark
On mac I got a fuzzy camera control and the floor is not uniform but we see tiles bordered of black. I know that this will not help you but I got other strange behavior.
Stef
On Friday, June 13, 2003, at 07:25 PM, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
It must be that Python stuff you've been fooling around with ....
Cheers,
Alan
-----
At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
--
Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.
Stephane, you might want to check your Mac bugs and see if they're new, too.
Mark
At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:
It must be that Python stuff you've been fooling around with ....
Cheers,
Alan
At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
--
______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Hi mark
It works in 3.4. When I create a Wonderland I got a good looking ground and camera controls I also rechecked with 3.5 5180 and to my surprise it works there too. So I'm puzzled. May be there is something corrupting it in one my projects I used but I do not see because I'm extremely careful with projects. Stef
On Monday, June 16, 2003, at 06:05 PM, Mark Guzdial wrote:
Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.
Stephane, you might want to check your Mac bugs and see if they're new, too.
Mark
At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:
It must be that Python stuff you've been fooling around with ....
Cheers,
Alan
At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
--
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Hi Guys,
For preparing a demo I need some code which is capable of reading and writing animated GIFs. While this particular demo can work without the support it would make an incredible difference if someone would have some code for dealing with it. Doesn't have to be anything special, just the ability to encode and decode a few simple images from/to GIF. Since the basic support is already in Squeak it shouldn't be too hard to make this work.
BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.
Thanks for any help you can provide.
Cheers, - Andreas
On Monday 16 June 2003 10:35 pm, Andreas Raab wrote:
BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.
Thanks for any help you can provide.
IIRC Tansel said that there's some (fairly) functional code in the Squeak News isos: come to think of it, it must be pretty near fully functional -- remember the flying Stork?
Cheers
John
Hi
Working on a Genie demo I have just realized that the TransformationMorph does not seem to work properly with translucent colors. As an example, do the following:
- Create a EllipseMorph and open it - Change the color of the ellipse to a translucent color (e.g., "self color: (Color red alpha: 0.5)") - Open the halos on the EllipseMorph and rotate it.
You will see that the translucency goes away and the EllipseMorph suddenly appears in a weird color. Also if you change the color of the Ellipse again (e.g., to another translucent color), this does not work properly.
Is this problem known? If not, can someone try to fix it? (I'm extremely short on time right now and so it would be great if I didn't have to dive into this myself).
Nathanael
PS: I'm pretty sure that this problem is caused by the TransformationMorph the Ellipse is embedded into when rotated.
Tested this out in a 3.7 5816 image. It still appears to be happening
Here you'll find a gif writter:
http://groups.yahoo.com/group/squeak/message/62471
Cheers,
Diego
Hi Guys,
For preparing a demo I need some code which is capable of reading and writing animated GIFs. While this particular demo can work without the support it would make an incredible difference if someone would have some code for dealing with it. Doesn't have to be anything special, just the ability to encode and decode a few simple images from/to GIF. Since the basic support is already in Squeak it shouldn't be too hard to make this work.
BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.
Thanks for any help you can provide.
Cheers,
- Andreas
Am Montag, 16.06.03 um 23:35 Uhr schrieb Andreas Raab:
Hi Guys,
For preparing a demo I need some code which is capable of reading and writing animated GIFs. While this particular demo can work without the support it would make an incredible difference if someone would have some code for dealing with it. Doesn't have to be anything special, just the ability to encode and decode a few simple images from/to GIF. Since the basic support is already in Squeak it shouldn't be too hard to make this work.
BTW, if you have some half-baked (sometime started but never finished) code lying around I'd be willing to clean it up so that we can use it from GIFReadWriter along with the other stuff.
Thanks for any help you can provide.
This should wind up in the update stream soon (it was [approved] already)
http://swiki.gsug.org/sqfixes/3341.html
Writing only, though. Reading shouldn't be too hard either.
-- Bert
Bert Freudenberg wrote:
Am Montag, 16.06.03 um 23:35 Uhr schrieb Andreas Raab:
Hi Guys,
For preparing a demo I need some code which is capable of reading and writing animated GIFs. ...
This should wind up in the update stream soon (it was [approved] already)
http://swiki.gsug.org/sqfixes/3341.html
Hmm, this should have gone in the update stream awhile ago. It seems that I missed a few items approved around June 4th for some reason... I'll add those in with the next batch. (My excuse is that the text filtering wasn't working in the BugFixArchiveViewer when I tried it a few days ago. :-) I'll do a more thorough check with the next batch.)
- Doug Way
Next clue: It's the 3.4 and 3.5 Windows VMs. If I open the latest 3.5 image in a 3.2 VM, Alice works just fine. But if I try to open any model in Alice with a 3.4 or 3.5 VM, Squeak crashes on XP.
Mark
At 12:05 PM 6/16/2003 -0400, you wrote:
Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.
Stephane, you might want to check your Mac bugs and see if they're new, too.
Mark
At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:
It must be that Python stuff you've been fooling around with ....
Cheers,
Alan
At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
--
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
I've tracked my Alice bug down to:
Form fromFileNamed: 'anything.bmp'
I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The same BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.
Who maintains the Windows VM these days? Is there anything that's changed between 3.2 and 3.4 that would effect reading BMP's?
Thanks! Mark
At 09:27 PM 6/16/2003 -0400, Mark Guzdial wrote:
Next clue: It's the 3.4 and 3.5 Windows VMs. If I open the latest 3.5 image in a 3.2 VM, Alice works just fine. But if I try to open any model in Alice with a 3.4 or 3.5 VM, Squeak crashes on XP.
Mark
At 12:05 PM 6/16/2003 -0400, you wrote:
Certainly a possibility, but it must be a NEW anti-Python virus. I just checked -- Squeak 2.7 and 3.2 work fine. It's only 3.4 and 3.5 where Alice dies when I open a model.
Stephane, you might want to check your Mac bugs and see if they're new, too.
Mark
At 02:11 PM 6/13/2003 -0800, Alan Kay wrote:
It must be that Python stuff you've been fooling around with ....
Cheers,
Alan
At 1:25 PM -0400 6/13/03, Mark Guzdial wrote:
I can't open any models in Squeak Alice, in either 3.4 nor 3.5. Wonderland new works, and I can control the bunny in the Worlds of Squeak, but whenever I try to open a model (either "in editor" via the FileList or via "w makeActorFrom: 'pathname'"), I see the pieces showing up in the hierarchy of parts view, but then all of Squeak crashes -- the window just collapses. No log or debug file is generated. I've tried both the Objects.zip from UIUC and the SqueakObjects.zip on Jeff's account at CMU.
This is on a Dell Latitude running XP, even downloading a fresh 3.5 image. Jeff Pierce is trying this, too, and isn't having any problem, so it must be something weird about my setup. Anyone ever seen anything like this?
Mark
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
--
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Mark Guzdial guzdial@cc.gatech.edu wrote:
I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The same BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.
Well it's done by the BMPReadWriterPlugin. Since it was in-image code until 3.6, I guess the evidence comes from the changes file. Hmm, the plugin was added in update 4891 from code by Andreas dated 16 june 2002. This was nominally for 3.3a and I can't spot any difference with the code in my latest VMMaker file. I _have_ tested this on my Acorn and it works fine. I guess using the 3.2 vm means you're relying on the back up code. Obvious quick check is to comment out the primitive call in !BMPReadWriter methodsFor: 'reading' stamp: 'ar 6/16/2002 18:47'! read24BmpLine: pixelLine into: formBits startingAt: formBitsIndex width: width | pixIndex rgb bitsIndex | <primitive: 'primitiveRead24BmpLine' module:'BMPReadWriterPlugin'> pixIndex _ 0. "pre-increment" and see if all seems well. After that it requires someone to debug the code on a wondows machine...
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim No single raindrop believes it is to blame for the flood
I did try BMP reading for 3.5 on an XP machine, and it worked ok.
Eddie
---- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, June 18, 2003 5:48 PM Subject: Re: [BUG] Can't read BMPs in 3.4/3.5 Windows VM (was Re: [bug?] Problems with Alice -- can't open new models)
Mark Guzdial guzdial@cc.gatech.edu wrote:
I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The
same
BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM,
trying
to read the BMP crashes Squeak.
Well it's done by the BMPReadWriterPlugin. Since it was in-image code until 3.6, I guess the evidence comes from the changes file. Hmm, the plugin was added in update 4891 from code by Andreas dated 16 june 2002. This was nominally for 3.3a and I can't spot any difference with the code in my latest VMMaker file. I _have_ tested this on my Acorn and it works fine. I guess using the 3.2 vm means you're relying on the back up code. Obvious quick check is to comment out the primitive call in !BMPReadWriter methodsFor: 'reading' stamp: 'ar 6/16/2002 18:47'! read24BmpLine: pixelLine into: formBits startingAt: formBitsIndex width:
width
| pixIndex rgb bitsIndex | <primitive: 'primitiveRead24BmpLine' module:'BMPReadWriterPlugin'> pixIndex _ 0. "pre-increment" and see if all seems well. After that it requires someone to debug the code on a wondows machine...
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim No single raindrop believes it is to blame for the flood
Thanks, Tim -- I tried this. I commented out the <primitive> line in the method you mentioned. Same difference -- Squeak still dies without crash.dmp.
Mark
At 02:48 PM 6/18/2003 -0700, you wrote:
Mark Guzdial guzdial@cc.gatech.edu wrote:
I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The
same
BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.
Well it's done by the BMPReadWriterPlugin. Since it was in-image code until 3.6, I guess the evidence comes from the changes file. Hmm, the plugin was added in update 4891 from code by Andreas dated 16 june 2002. This was nominally for 3.3a and I can't spot any difference with the code in my latest VMMaker file. I _have_ tested this on my Acorn and it works fine. I guess using the 3.2 vm means you're relying on the back up code. Obvious quick check is to comment out the primitive call in !BMPReadWriter methodsFor: 'reading' stamp: 'ar 6/16/2002 18:47'! read24BmpLine: pixelLine into: formBits startingAt: formBitsIndex width: width | pixIndex rgb bitsIndex | <primitive: 'primitiveRead24BmpLine' module:'BMPReadWriterPlugin'> pixIndex _ 0. "pre-increment" and see if all seems well. After that it requires someone to debug the code on a wondows machine...
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim No single raindrop believes it is to blame for the flood
______ Mark Guzdial, Associate Professor, College of Computing/GVU http://www.cc.gatech.edu/~mark.guzdial/ Collaborative Software Lab http://coweb.cc.gatech.edu/csl
Mark Guzdial wrote
I've tracked my Alice bug down to:
Form fromFileNamed: 'anything.bmp'
I can't read any BMP's with a 3.4 or 3.5 Windows VM on an XP box. The
same
BMP's open just fine in 3.2. It's a VM-level bug because I can read the BMP's in a 3.5 image running in a 3.2 VM. But in a 3.4 or 3.5 VM, trying to read the BMP crashes Squeak.
MobVM MultiMedia release (tracking 3.4.4) and squeak 3.5, a PrintIt on:
Form fromFileNamed: 'F:\squeak\AliceObjects\Animals\cat.bmp'
gave 'ColorForm(256x256x8)'
Any bitmap file can be open (viewed) via FileList without problem.
However,
w makeActorFrom 'F:\squeak\AliceObjects\Animals\cat.mdl'
or 'Load actor' to 'scene' (from a Wonderland Visual Studio), crashed Squeak without a stack trace:
-------------------------- crash.dmp start ----------------------------------------- Wed Jun 18 22:13:36 2003
Exception code: C0000005 Exception addr: 01607A0F Access violation (read access) at 7A000000 EAX:BD000000 EBX:1AF5E408 ECX:1AF5AF4C EDX:00000030 ESI:00000014 EDI:00000038 EBP:1AF82228 ESP:0012FE70 EIP:01607A0F EFL:00010246 FP Control: FFFF027F FP Status: FFFF1963 FP Tag: FFFFFFFF VM Version: MobVM - RFC version - MultiMedia Release(Tracking 3.4.4) May 21 2003 Compiler: Microsoft Visual C++
Current byte code: 211 Primitive index: 130
Loaded plugins: JPEGReadWriter2Plugin 5 September 2002 (e) Squeak3D 9 March 2003 (e) LargeIntegers v1.2 5 September 2002 (e) B2DPlugin 5 September 2002 (e) FloatArrayPlugin 5 September 2002 (e) Matrix2x3Plugin 5 September 2002 (e) BitBltPlugin 9 November 2002 (e) MiscPrimitivePlugin 5 September 2002 (e) WindowPlugin September 2002 (e) DropPlugin 5 September 2002 (e) FilePlugin 5 September 2002 (e) SecurityPlugin 5 September 2002 (e) MegaInterpreterPlugin Halloween 2002 (e) ModManPlugin May 21 2003 (e) PlatformPlugin September 2002 (e) SqMOM September 2002 (e) PlugManPlugin September 2002 (e) MicroKernel February 2003 (i)
Stack dump: [EMPTY]
-------------------------- crash.dmp end -----------------------------------------
and Tim wrote:
... it requires someone to debug the code on a wondows machine...
Preliminary investigations indicated that this bug is nasty and dirty. It's in the garbage collector.
It always crashed in primitive 130:
primitiveFullGC >>> incrementalGC() >>> incCompBody() >>> mapPointersInObjectsFromtomapPointersInObjectsFromto()
It happened at different spots on different models, on different ways of tracing (debugging).
Sometimes it happened here:
newOop = longAt(fwdBlock4); // <<<< CRASH
Some other times, here:
newClassOop = longAt(fwdBlock3); // <<<< CRASH
Does it ring a bell ?
Cheers,
PhiHo.
I wrote:
Preliminary investigations indicated that this bug is nasty and dirty. It's in the garbage collector. It always crashed in primitive 130:
This morning, I tried on a machine at work and couldn't reproduce it. This evening, it couldn't be reproduced on the same machine used last night.
As I said, this bug is nasty and dirty. ;-)
I give up.
Cheers,
PhiHo.
It's very unlikely that this is a bug in the GC code. Crashing in prim 130 means nothing - much more plausible is that the BMP loading code is corrupting memory and the corruption causes GC to go mental.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System
Ya, I think the last GC bug we had which was related to class changing and process switching where one forgot to remember to swap an instance variable was 2-3? years ago. This is not to say there couldn't be a bug, however in my experiences any GC crash is related to some primitive trashing memory.
If you've seen the visualworks source code, why every step of the way in the debug vm, there are assert checks to confirm there are no buffer overflow conditions and everything in sight is confirmed as valid. We aren't as paranoid in Squeak.
I'd suspect one would need to look at the BMP code and start coding up asserts to confirm there are no memory overwrite conditions.
For example I just fixed a problem in the SerialPort Read Primitive were a size check is made, but on a failure just the success flag is set (prim failed), and the vm cheerfully executes the memory trashing. It never has been an issue because the primitive call is setting up the right values, still I was surprised to see it was defective.
On Friday, June 20, 2003, at 11:47 AM, Tim Rowledge wrote:
It's very unlikely that this is a bug in the GC code. Crashing in prim 130 means nothing - much more plausible is that the BMP loading code is corrupting memory and the corruption causes GC to go mental.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi John,
Ya, I think the last GC bug we had which was related to class changing and process switching where one forgot to remember to swap an instance variable was 2-3? years ago. This is not to say there couldn't be a bug, however in my experiences any GC crash is related to some primitive trashing memory.
I tend to agree with Tim and you about this. That's why it was categorised as 'nasty and dirty' ;-)
But Mark reported a crash when he evaluated:
Form fromFileNamed: 'anything.bmp'
I could never reproduce this. However I could randomly crashed Squeak when I tried to makeActorFrom cat.mdl. Sometimes I got a cat sometimes I got a crash before my first post.
After my first posting, I tried several times on two diffrent machines and could not reproduce it even when loading mutiple actors, one after another.
How can this behavior be explained ? What can cause Squeak to crash in a non-reproducible manner ?
If the loading of BMP is corrupting the memory, would the crash be reproducible every time ?
To me this bug seems to be dependent on environment. Maybe Mark can clarify this by trying to reproduce it under different environments.
I also noticed a few things that may be helpful for further investigations:
1/- primitiveFullGC (130) is never called during my game session (FreeCell, Tetris)
2/- primitiveFullGC is not called when I evaluated:
Form fromFileNamed: 'F:\squeak\AliceObjects\Animals\Chicken.bmp'
3/- primitiveFullGC is not call when I open/view same bitmap via FileList.
4/- primitiveFullGC is called many times when I open 'Chicken.mdl' once for every part of the chicken, namely:
left leg, left foot, right leg, right foot, neck, head, upperLip, lowerLip.
who, what are responsible for the GC call ?
5/- at this point sometimes it crashed, sometimes it didn't, but if it did not crash, it did not show me the chicken either (not even in the garbage bin ;-)
Where is my chicken ? Is this reproducible on other platforms.
Cheers,
PhiHo.
----- Original Message ----- From: "John M McIntosh" johnmci@smalltalkconsulting.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, June 20, 2003 4:10 PM Subject: Re: [BUG] Can't read BMPs in 3.4/3.5 Windows VM (was Re: [bug?] Problems with Alice -- can't open new models)
Ya, I think the last GC bug we had which was related to class changing and process switching where one forgot to remember to swap an instance variable was 2-3? years ago. This is not to say there couldn't be a bug, however in my experiences any GC crash is related to some primitive trashing memory.
If you've seen the visualworks source code, why every step of the way in the debug vm, there are assert checks to confirm there are no buffer overflow conditions and everything in sight is confirmed as valid. We aren't as paranoid in Squeak.
I'd suspect one would need to look at the BMP code and start coding up asserts to confirm there are no memory overwrite conditions.
For example I just fixed a problem in the SerialPort Read Primitive were a size check is made, but on a failure just the success flag is set (prim failed), and the vm cheerfully executes the memory trashing. It never has been an issue because the primitive call is setting up the right values, still I was surprised to see it was defective.
On Friday, June 20, 2003, at 11:47 AM, Tim Rowledge wrote:
It's very unlikely that this is a bug in the GC code. Crashing in prim 130 means nothing - much more plausible is that the BMP loading code is corrupting memory and the corruption causes GC to go mental.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org