uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Commented: (UIMA-210) faulty use of .read(buffer...) in several places - not checking for fewer than expected bytes/chars read
Date Mon, 12 Feb 2007 19:57:05 GMT

    [ https://issues.apache.org/jira/browse/UIMA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472399
] 

Marshall Schor commented on UIMA-210:
-------------------------------------

Things I've learned since my last comment above:
1) StringBuffer is probably smart and won't reallocate it's buffer during toString().
2) if (otherObject = null) will give compiler error (result isn't a boolean).  My thinking
must be left over from "C" coding :-)


> faulty use of .read(buffer...) in several places - not checking for fewer than expected
bytes/chars read
> --------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-210
>                 URL: https://issues.apache.org/jira/browse/UIMA-210
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.1
>            Reporter: Marshall Schor
>         Assigned To: Marshall Schor
>             Fix For: 2.1
>
>
> The definition of most instances of stream.read(bufferArray) says it reads *up to* the
length of the array.  We had earlier an issue on a multi-core machine where the length read
was much less than the length of the buffer or of the file. (This was in Vinci).  The solution
is to wrap these things in code that looks like this from the XTalkTransporter (this assumes
the file length is known):
>   static public void readFully(byte[] b, int length, InputStream in) throws IOException
{
>     int read_so_far = 0;
>     while (read_so_far < length) {
>       int count = in.read(b, read_so_far, length - read_so_far);
>       if (count < 0) {
>         throw new EOFException();
>       }
>       read_so_far += count;
>     }
>   }
> Code which is broken can be found by scanning for .read(
> Ones I found scanning are:
> VinciTAEClient
> FileUtils (copyFile method) 
> (Note: similarly named class FileUtil (no final "s") has a copyFile method that is OK)
> XMLUtil.java has fragment that could fail incorrectly in detectXmlFileEncoding:
>       // store the 1st text byte and read next 6 bytes of XML file
>       buffer[byteCounter++] = (byte) nextByte;
>       if (iStream.read(buffer, byteCounter, bytes2put - 1) != bytes2put - 1)   //ERROR
NOT ALLOWING FOR FEWER BYTES READ
>         throw new IOException("cannot read file");
> There are multiple instances of code in JcasSofaTest don't allow for the possiblity of
reading fewer than buf size; here's one:
>       dest = new byte[4];
>       is.close();
>       is = intArrayView.getSofaDataStream();
>       assertTrue(is != null);
>       int i = 0;
>       while (is.read(dest) != -1) {
>         assertTrue(ByteBuffer.wrap(dest).getInt() == intArrayFS.get(i++));
>         ;
>       }
> And another one like this in SofaTest.
> DebugControlThread method doCheckpoint has the problem
> In our examples, the following have the problem:
> CasMultiplierExampleApplication 
> FileSystemCollectionReader
> ExampleApplication
> PrintAnnotations
> JetExpander
> And in uimaj-tools:
> FileSystemCollectionReader
> CasTreeViewer

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message