argfiles parsing broken for argfiles > 4096 bytes
Robert Stupp
snazy at gmx.de
Thu Mar 5 19:34:59 UTC 2020
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
line.
The bug happens when the last character of a comment line is the 4096th
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 nextToken())
with the contents of the current comment line. The next "valid" option
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 line.
I've also tried and changed this line
http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l294
to 'if (anchor != nextc && pctx->state == IN_TOKEN)' and the argfile is
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 #
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-Dfoo=bar
Caused by: java.lang.ClassNotFoundException: #
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-Dfoo=bar
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.
Robert
On Thu, 2020-03-05 at 20:00 +0100, Robert Stupp wrote:
> Hi,
...
>
More information about the core-libs-dev
mailing list