RFR: 8146793: logStream::write re-formats string
John Rose
john.r.rose at oracle.com
Wed Jan 20 02:06:15 UTC 2016
On Jan 19, 2016, at 5:07 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>
> It doesn't look like the logging code has anything like that. I think
> it would need to be an addition to Log<>::vwrite. [I'd thought about
> trying to improve this path from logStream some way, but decided I was
> mostly interested in fixing the crashing bug, and could leave
> optimizing this path to others if needed.] I'll file an RFE for this.
Thank you. If you get inspired to roll this in now, I'd support that.
>> Nice catches on the va_copy and buffer overrun. How did you find
>> the log_func(foo) instead of log_func("%s", foo)? Please tell me it
>> was a gcc warning; if not then we have some software rot going on.
>
> Sorry, but I found it the hard way, via a crash (I think it was the
> assert in Log<>::vwrite). logStream::_log_func is a function pointer.
> Maybe we can attach an ATTRIBUTE_PRINTF to the data member and/or to
> the logStream constructor argument? And maybe that would produce the
> desired warnings? I think attaching that attribute would have
> generated a warning for the non-literal format string being passed to
> _log_func.
OK, yes; that's what I mean by software rot. We went to a lot of
trouble to annotate and fix the the format problems, and now they
are building up again as people add new functions without the
annotation. Putting in the annotations is really part of making
a firm fix to the "%s" problem, not just reacting to crashers as
they show up. Fix the root cause, not just the crash.
— John
More information about the hotspot-dev
mailing list