argfiles parsing broken for argfiles > 4096 bytes
snazy at gmx.de
Thu Mar 5 19:43:07 UTC 2020
Another note: I've also seen it appending a comment-line in
with pctx->state==IN_COMMENT, but wasn't able to reconstruct the
behavior with a "clean" argfile. But that behavior was also fixed with
the condition ('&& pctx->state == IN_TOKEN') added by the patch.
On Thu, 2020-03-05 at 20:34 +0100, Robert Stupp wrote:
> Sorry for the broken formatting...
> I recently came across a bug in the java executable with an argfile
> that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment
> The bug happens when the last character of a comment line is the
> byte and the trailing newline is the first byte in the next chunk. In
> that case, nextToken() in src/java.base/share/native/libjli/args.c
> calls JLI_List_addSubstring (in the if-block at the end of
> with the contents of the current comment line. The next "valid"
> gets appended to that comment line and java errors out.
> I've added some debugging output to the last if-block and pctx->
> state==FIND_NEXT and the the substring being added is the comment
> I've also tried and changed this line
> to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile
> parsed correctly.
> Steps to reproduce:
> 1. save the attached my-argfile
> 2. run 'java @my-argfile my.className'
> 3. java errors out with
> Error: Could not find or
> load main class #
> Caused by: java.lang.ClassNotFoundException: #
> With the above change (the attached patch in argfile-parse-bug.txt),
> argfile parsing works as expected.Also updated the condition in the
> loop looking for a comment's newline, as it looks inconsistent to the
> condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of
> the outer for-loop.
> On Thu, 2020-03-05 at 20:00 +0100, Robert Stupp wrote:
> > Hi,
More information about the core-libs-dev