RDROYA01@ULKYVX.BITNET.UUCP (06/01/86)
I just discovered a "strange bug" with the jsr to CCP routine I sent out. It is strange in that it appears, consistently, under an extreme set of circumstances. The only work around I have found is simple but perplexing. If you are compiling a series of programs using the supplied C.SUB file, and you want to compile the programs from within the suspended program, then you cannot stay in background CCP for more than two trips through the SUB file without returning to the suspended program. Invariably on the third straight compilation C168 returns a "Read error on program load." No other program produces this error, and C168 doesn't produce it on the first or second run through. However, the system crashes after this error because the bottom of the suspended program is blown away by the attempt to load. Keep in mind the TPA has been *permanently* reset, the stacks have been saved at the very top of old memory, which is significantly higher than the memory the BDOS thinks it has to work with. (I checked this by running a return TPA size program.) I know the original user stack is intact because the RTE operates properly, returning to the calling function. The actual crash occurs when the returned to function calls another function that I know to be near the beginning of the program's text base. But even though there is a 256 byte "no-man's-land" between TPA top and the beginning of the suspended program, the load prog function manages to trash the lowest parts of that program. If you compile the modules one at a time, and after each run through C.SUB you return to the suspended program, there appears to be no restriction on the number of times the SUB program can be run, and no program load error occurs. This is a little annoying but also intriguing. Anyone got any ideas?