[M3devel] thread test results on Win7 64-bit

[Daniel Alejandro Benavides D.]

Hi all:
reading through the green book chapter on IO streams, p160, it seems, there should not be such a range violation cause its actually allowed to be NIL (see  ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-053.html
p 30 and above) so this must be related to the fact there is some missing a conditional if so as it is unsafely checked by the compiler, but it might not be necessarily that, I mean unsafe perse, but in that case just for that may get a RT error unneeded to argue for that (i.e it might not), indeed most of the crashes might come by this classes, but as I read TextWr seek method style was to raise an unlisted exception which is by itself a RT error as a policy, however subclasses of Rd.T must be aware of their obligations that is, they have invariants so we could  check for those I believe they are there in safe MODULES (as I think is checked already) and manner that is even as one could argue in UNSAFE modules they hold (if they don't hold just the first case), we could if this is really broken get it in safe modules to check for them in an ESC, actually first RW lib was absolutely according to their comments unsafe for speed performance but after
 crashed many times decided to made safe interfaces to look for those kind of errors. So it might be need a middle layer not UNSAFE module of FileRd INTERFACE to look for those errors closely, e.g implement that method failing (FileRd.seek) and related safely and check them by ESC.
Specifically from the three invariants the most feasible mentioned in RdClass interface which might be not be satisfied and should be checked in a debugger is the first of the three (because would cause same RT error shown there):
rd is valid if =>
[rd.lo .. rd.hi-i] 
where i can be 0 and so buff=NIL, 
so its possible though would need confirmation a breakpoint there in line FileRd.m3:83 to see rd.buff
the others that come after this, 
cur(rd) = MIN(rd.cur,  len(rd))
from what
rd.cur>len(rd) or rd.cur = len(rd)
and third:
NOT (rd.intermittent AND rd.seekable)
That said I would recommend the latter method a mechanic debugger meanwhile, tough if positive we would follow the guideline of Greg and the gang to specify it in a safe module, at least the method. Then in an automatic debugger might help to proof that for us too if so.
Indeed there are more classes of invariants there for declare clean and also private invariants too. Will check for that too.  
Thanks in advance

--- El jue, 17/3/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribió:

De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] thread test results on Win7 64-bit
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 17 de marzo, 2011 14:46

Tony et al:  On the surface, it would seem this convoluted code is doing the following:1.       Making rd.buff appear as an “ARRAY OF Byte”, vice an “ARRAY OF CHAR, so as to meet the requirements of the File.T.read interface.2.       Limiting the buffer to be the smaller of “BIG”, or the actual number of elements in rd.buff  Now, re #2, the code in FileRd seems to allocate buffers in 4096-char arrays, and BIG is 16M, so I don’t quite see why the need to ensure the buffer is limited to no more than BIG, as it should never be more than 4096.  All that aside, are you concerned that the GC could be relocating rd.buff after its address is obtained and fed to the File.T.read (rd.sourceH.read) procedure?  If indeed this movement can occur, this code definitely needs to change.  How can we force the GC not to move rd.buff, or is there another “safe” way to make rd.buff appear as an “ARRAY OF Byte” to satisfy the File.T.read
 interface?  Buffers are allocated in line #45 as a traced reference to an ARRAY OF CHAR via:      rd.buff := NEW(CharBuffer, BufferSize);Yet, the ByteArrayPtr in FileRd.m3 (line 25) is an untraced reference (to an array of Byte).  Should we be allocating buffers (rd.buff) as untraced refs instead, and then explicitly freeing?  Or, is there a way to keep them as traced refs, but avoid collection/movement while being used in an unsafe manner?  Finally, there are multiple statements in the FileRd.m3 module similar to line #83 that must be dealt with (e.g., 114, 119).  Regards,Randy Coleburn  From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
Sent: Wednesday, March 16, 2011 8:14 PM
To: Coleburn, Randy
Cc: m3devel
Subject: Re: [M3devel] thread test results on Win7 64-bit  This is the offending line:On Mar 16, 2011, at 6:50 PM, Coleburn, Randy wrote:  ****** runtime error:***    An array subscript was out of range.***    file "..\src\rw\FileRd.m3", line 83***        n := rd.sourceH.read(             SUBARRAY(LOOPHOLE(ADR(rd.buff[0]), ByteArrayPtr)^, 0,                      MIN (NUMBER(rd.buff^), BIG)), mayBlock := NOT dontBlock)  I am very suspicious about this...  anyone have any insights?  


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110318/0138ec00/attachment-0002.html>