AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (01/29/89)
>Date: Sun, 22 Jan 89 12:59:40 CST >From: Brian Greenstone <orcus@PRO-LEP.CTS.COM> >Subject: RE: Pascal bug in GS/OS and GS/OS bugs. >In response to the letter about using TML pascal with GS/OS and a >crash occuring, you might want to know that there is a apparently a >bug in GS/OS's loader that occasionally writes "mystery" bytes into >programs. I found the bug in an assembly program that Im writing and >after many days of testing found that for some reason, GS/OS writes a >few random bytes into the same place in memory. Please be specific so I can try to verify the bug and report it through official channels. How many bytes get trashed, where are they, does it _always_ happen or just for your particular program, etc. Are you _sure_ the trashing is happening when your program is loaded and _not_ while your program is already running? (Messing up the B register in your program would be a very effective way of trashing your code instead of loading/storing global variables, for example. Really...I've done it!) >Also, GS/OS has a screwed up file size indicator. If you go into >Paintworks Gold or anyother program and create a file (picture) which >is mostly $00's (black screen) and you save it unpacked, the file >size will be much much smaller than the 32K that it should be, and >thus PaintWorks will not read the picture back in. Uhh, no. The file, as a logical entity, is still $00008000 (32768) bytes long, but it does not necessarily take 65 blocks on disk. Under the ProDOS File System Translator (PRO.FST) in GS/OS, any block in a file which would be all zeroes is not allocated on disk, but the zeroes are still in the file. If you had tried to verify your hypothesis that the block count was _wrong_ by putting more than 24 of the unpacked 32K files on a 800K disk, you would have found that the block counts are perfectly correct. PaintWorks makes a major blunder by assuming that a 32K file will always take 65 blocks. Even before GS/OS, this assumption was false on an AppleShare network. The block count there would be 64, since there is no index block in the count. >Also, if you take any other previously created picture which is >mostly $00's and you try to copy it with any GS/OS application (ie >the Finder), the new copy will be the wrong file size. Understand >that GS/OS is not packing the file at all, it is simply writing the >wrong block usage number into the directory listing. The ProDOS FST is doing the trick, and a ProDOS file is called "sparse" if some areas of it are not stored on disk. --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
keith@Apple.COM (Keith Rollin) (01/30/89)
In article <8901281420.aa10989@SMOKE.BRL.MIL> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>Date: Sun, 22 Jan 89 12:59:40 CST >>From: Brian Greenstone <orcus@PRO-LEP.CTS.COM> >>Subject: RE: Pascal bug in GS/OS and GS/OS bugs. > >>In response to the letter about using TML pascal with GS/OS and a >>crash occuring, you might want to know that there is a apparently a >>bug in GS/OS's loader that occasionally writes "mystery" bytes into >>programs. I found the bug in an assembly program that Im writing and >>after many days of testing found that for some reason, GS/OS writes a >>few random bytes into the same place in memory. > >Please be specific so I can try to verify the bug and report it >through official channels. How many bytes get trashed, where are >they, does it _always_ happen or just for your particular program, >etc. Are you _sure_ the trashing is happening when your program is >loaded and _not_ while your program is already running? (Messing up >the B register in your program would be a very effective way of >trashing your code instead of loading/storing global variables, for >example. Really...I've done it!) > Brian and Dave, This might be one that we know about. I remember that the Loader itself had the problem with not setting the B register, and was trashing two bytes in memory. I thought that it was fixed in System Disk 4.0, but I could be wrong. I can't remember many of the characteristics, except that it really only shows up with large, multi-segmented programs. We found this out after driving the author of Medley insane by trying to track down this bug. Also, the term "Bank $06" comes to mind when I think of this bug. In any case, Dave is right -- please let us know more about the problem. That way we can track it down and nuke it. Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "You can do what you want to me, but leave my computer alone!"