BS2000/CRTE/fwrite-error at 128MB

[lzsiga]

I have found a strange bug in CRTE V02.4A15, which can be reproduced with teh following program:<P>/* fwrt.c */<P>#include <stdio.h><BR>#include <stdlib.h><BR>#include <string.h><P>int main (int argc, char **argv)<BR>{<BR> FILE *f;<BR> char *buff;<BR> int i;<P> buff = malloc (16384);<BR> system ("FILE FWRTEST,LINK=FWRLINK,FCBTYPE=PAM");<BR> f = fopen ("link=FWRLINK", "wb");<BR> if (f==NULL) {<BR> perror ("fopen");<BR> exit (12);<BR> }<BR> if (argc>1 && strcasecmp (argv[1], "fprintf")==0) {<BR> fprintf (f, "--HEADER--");<BR> } else {<BR> fwrite ("--HEADER--", 1, 10, f);<BR> }<BR> for (i=0; i<8300; ++i) {<BR> fwrite (buff, 1, 16384, f);<BR> }<BR> fclose (f);<BR> return 0;<BR>}<P>The program will die if started with option "fprintf" and will work if started with option "fwrite"

[lzsiga]

The problem is related with PAM files handled with DIV access method...<BR>

[lzsiga]

The problem is not with 'fprintf', I can write instead<BR>printf ("--HEADER--");<BR>fwrite ("--HEADER--", 1, 10, f);<P>printf has no relation with file "f" at all, it just requests a new stack-seqment allocatation (IT0SRQM), which happens to be allocated at (char *)f+0x2000.<BR>Later (after writing about 128 MiB), somewhere in ICSVIIO.IC@VCOW the content of this address (8001FEFF = ASA indicator) will be (mis)used...<P>The next thing I will try is closing and reopening the file after writing 64MiB...

[lzsiga]

Here is an interesting thing: the critical address is (char *)f+0x2000. Perhaps this problem is related witch memory allocation: CRTE calls REQM to alloc the page at (char *)f+0x2000 (or to alloc two pages at (char *)f+0x1000). The page is already allocated, a warning is returned. If CRTE ignores the warning it will thing that the allocated page is filled with zero...<P>I have an idea what to try: force BLKSIZE=STD(1) in FILE-command, which (I hope) will force use of UPAM instead of DIV.

[lzsiga]

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by lzsiga:<BR><B>Here is an interesting thing: the critical address is (char *)f+0x2000. Perhaps this problem is related witch memory allocation: CRTE calls REQM to alloc the page at (char *)f+0x2000 (or to alloc two pages at (char *)f+0x1000). The page is already allocated, a warning is returned. If CRTE ignores the warning it will thing that the allocated page is filled with zero...</B><HR></BLOCKQUOTE><P>No, there is a descriptor table at (char *)f+0x1000 (address is stored in (char *)f+0x3c), each entry is 8B long, contains flags(4B) and address(4B). Each entry describes 256KiB of file. This describes (4096/8)*256KiB=128MiB. The problem occurs, when the file reaches this size, CRTE overruns the descriptor-table, and reads the bytes after it.<P>

[lzsiga]

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by lzsiga:<BR><B>I have an idea what to try: force BLKSIZE=STD(1) in FILE-command, which (I hope) will force use of UPAM instead of DIV.</B><HR></BLOCKQUOTE><P>This works!<BR>I think I'll finish the saga here, maybe in the next version this bug will be fixed...

[Juggernaut]

nice 1-man-thread, though [img]/talk2/ubb-files/smile.gif[/img]<BR>

[lzsiga]

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by lzsiga:<BR><B>I have found a strange bug in CRTE V02.4A15</B><HR></BLOCKQUOTE><P>This is the version of the object module, the CRTE product version is V02.2A15<P>

[lzsiga]

The program seems working with BLKSIZE STD(1),3,4,5..,15,16, dumps only with STD(2)...<BR>Perhaps one could test with more data...