RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

[Cheleswer Sahu]

Hi David,

-----Original Message-----
From: David Holmes 
Sent: Friday, March 18, 2016 2:42 PM
To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
> Hi,
>
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JDK-8151442.
>
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>
> Bug Brief:
>
> In jstack thread dumps , thread name greater than 1996 characters 
> doesn't close quotation marks properly.

Anyone giving a thread a name that long deserves to get a core dump! ;-)

> Problem Identified:
>
> Jstack is using below code to print thread name
>
> src/share/vm/runtime/thread.cpp
>
> void JavaThread::print_on(outputStream *st) const {
>
>    st->print("\"%s\" ", get_thread_name());
>
> Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).
>
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
> char* format, va_list ap, bool add_cr) {
>
>    char buffer[O_BUFLEN];
>
> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>   "vsnprintf()"  which truncates the anything greater than the max 
> size(2000). In this case thread's name(> 1996) along with quotation 
> marks (2)
>
> plus one terminating character exceeds the  max buffer size (2000), 
> therefore the closing quotation  marks gets truncated.
>
> Solution:
>
> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>
> 1.st->print("\"%s", get_thread_name());
>
> 2.st->print("\" ");
>
> This will ensure presence of closing quotation mark always.

Can't we just limit the number of characters read by %s?
 
Yes we can do it, but just one thing which I think of is, if the truncation of output inside  output stream issue get resolves as Dmritry suggested or O_BUFFLEN size gets increased in any  future fix then we have to again make changes in this code, as limiting the no. of character read by %s will give truncated output . In such case present fix will have no effect.
 
David

> Regards,
>
> Cheleswer
>