Topic: PRINT USING Bug

[Hydrophilic]

Here is a bug that is very difficult to replicate.  For a quite a while I thought this was caused by the well-known CHAR bug, or perhaps my VDC mouse code.  But when the problem occurred in 40-column mode also, I knew it wasn't CHAR or the VDC mouse code.
 
It *seems* that if you are using a 'dynamic string' as a parameter to PRINT USING and garbage collection is called during PRINT USING that the format string is trashed, and thus the printed string is also garbage.
 
By 'dynamic string', I mean one that is built from an expression and not simply a variable name.  For example, CHR$(34)+M$+CHR$(34).
 
Because nearly 64K is normally available for variables, the chances that garbage collection will occur in a PRINT USING statement is usually low.  But if you reduce the variable storage area for other uses (like audio / video buffers), then the chance increases greatly.  However, even in such a case, and assuming you do a lot of PRINT USING commands, the chance is still quite low.
 
In fact I've spent 5~10 minutes now tring to reproduce the bug with no success... so I could be wrong, but PRINT USING seems to be the problem.  Searching for bugs with PRINT USING, I didn't find anything on this site, but Google found this page which relates to B-series of Commodores.  Those machines have more than a few similarities to the C128, so maybe it is the same bug??  It is hard to say because the page doesn't describe the PRINT USING bug itself, only that Commodore was aware that a bug existed and a revised ROM to fix the problem was produced but was never released.
 
Anyway, here is some example code, that if you run it long enough, have enough patience, and a have a lot of luck, should demonstrate the bug:
 

Code: [Select]

10 f$="##### ################ #####"
20 n=128:m$="filename":t$="prg"
30 do
40 print using f$; n, chr$(34)+m$+chr$(34), t$
50 loop
This just prints
128   "filename"     prg
forever, or until the bug strikes which then shows a bunch of garbage and keeps running...  If would crash when the bug occurrs, I could just run that demo until it crashed to have something to show you...
 
The only thing I can think to avoid the bug would be to assign the 'dynamic string' to a real string before invoking PRINT USING.  For example, replace line 40 above with this line

Code: [Select]

40 b$=chr$(34)+m$+chr$(34):print using f$; n, b$, t$
There is no gaurantee it will fix the problem, but it will slow down the program directly (more code) and indirectly (more frequent garbage collection).  So thought I would ask for any opinions or experience with this bug... thanks!
 
Edit
I finally got a screen shot of this bug.  I've attached two images, the good and the buggy.  As you can see in the bug view, the file size and file type are correct, but the filename (a dynamic string) is totally messed up! 
 
So now I've updated my BASIC code with the suggestion I mentioned above, but it is still too early to know if this fixes the problem because it is so rare...

[Wagner]

I couldn't reproduce this bug.  I tried lowering top of string storage down to $500, $600, $4ff, and $501, and waited several minutes each time, with my SCPU grinding away on the code provided.  Garbage collection should have done it's housekeeping scores of times in each case.  If some string becomes messed up, one would suppose it stays that way.

The erroneous text in your second picture looks like text from a function ROM.  I'm not running any extra ROM, so could that be the source of the error?

[Hydrophilic]

Thanks for trying, Wagner!  Like I said above, I couldn't reproduce the bug using the real code after trying for 15 minutes (using a list of 99 unique filenames).  I got that screen shot "by accident" when I was testing some files for playback...  It is extremely rare, as you can see.
 
No, I don't have any extra ROMs.  The error appears in VICE (PAL) and on my real NTSC machine.  The error appears in both 40 and 80 column modes.
 
After reading the directory but before playing any files, that's when I saw the error and made the screen shot.  However, it is not an error from reading the directory.  That info (directory stuff) goes into some variables (like the example code above).  So I can 'reprint' the list direct from memory without reading the directory again.  Reprinting the (unchanged) variables gave the 'good' screen shot posted above.
 
Now the "CBM" in the garbage might make you think it is something with cartridge/function ROM, but I think that has to do with "type" string which comes after the name.  It is an array of t$(i)="seq", "prg", "usr", "rel", "cbm", and "dir".  Maybe that is where the CBM seen in the garbage came from?
 
So maybe it is a bug with PRINT USING , dynamic strings, garbage collection, and arrays   Wow, what a very rare thing!
 
Anyway, a more accurate demo might be

Code: [Select]

10 f$="##### ################ #####"
15 dim t$(6): for i=1to6: read t$(i): next
20 n=128:m$="filename":i=2
30 do
40 print using f$; n, chr$(34)+m$+chr$(34), t$(i)
50 loop
60 data seq,prg,usr,rel,cbm,dir

I ran *that* test code for several minutes and did not see the bug.  But the screen shot in the first post proves that a PRINT USING bug does exist!

[Wagner]

So maybe it is a bug with PRINT USING , dynamic strings, garbage collection, and arrays?

Ran the suggested code (modified slightly, by randomly building up m$ with a FOR...NEXT loop within the DO...LOOP, and also randomly choosing the variable i) for over an hour, but saw no anomalies.  Albeit, I didn't watch it display most of that time--I simply returned after an hour.  The garbage collection caused a slight pause about every 10.5 seconds or so.

Did Commodore put out different versions of the C128 BASIC ROM?  I've heard that they sometimes quietly fixed bugs as they were found.  I'm thinking...PRINT USING...not that complicated.  Garbage collection...definitely more complicated.

[Hydrophilic]

There are several different ROM versions.  Most of them revolve around changes to the KERNAL for national character sets.
 
However for the standard/English character set, I believe there are only two versions.  In VICE I have the updated 1986 ROM, and in my flat C128 I have the old 1985 ROM.  The bug appears in both.
 
Also I would like to report that I have not seen the the bug again since applying the 'fix' mentioned in the first post.  But because the bug is so rare, that isn't saying much!

Edit
I spoke too soon!  About an hour or two after posting the above, I encountered the bug again!  This time in 40-column mode.  I had been thinking in the back of mind that *maybe* somehow reading the directory was messing up some pointers or something...
 
But this time it was already in memory.  And was displayed normally.  Then when I clicked the filename to highlight it... BAM!
 
The highlight function just prints a REVERSE ON character code then calls the same PRINT USING subroutine.  There is something messed really wrong and boy is tough to track down!
 
Also previously, the bug was just annoying but didn't do any damage.  But if you look in the new screen shot posted, you can see that this time the string is too long which caused the screen to scroll and mess up the GUI... grrr