RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe
Kevin Walls
kevinw at openjdk.org
Tue Nov 5 10:32:28 UTC 2024
On Tue, 5 Nov 2024 00:42:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash.
>
> testing: tier1,tier2,hs-tier5-svc
Hi,
List of tests doesn't mention tier4 where the failures were first noticed?
When PipeChannel::open logs error, and returns false, then Win32AttachOperation::open_pipe returns that value, then Win32AttachListener::dequeue() also logs that there was an error?
Is that message just a less detailed duplicate?
(it states whether it's v1 or v2, but maybe that's not that interesting?)
In the v2 case, Win32AttachListener::dequeue() will log if open succeeded, if !op->read_request().
But AttachOperation::read_request mostly logs its own errors as well.
I think it's only this one:
639 if (buffer_size < 0) {
640 return false;
...where it does not log when returning false. Maybe it should log then, and Win32AttachListener::dequeue() does not need to log?
While are are here, is it possible to address these at the same time?
open/src/hotspot/share/services/attachListener.cpp
typo "ot" -> "or"
631 case ATTACH_API_V2: // <ver>0<size>0<cmd>0<arg>0<arg>0<arg>0
632 if (AttachListener::get_supported_version() < 2) {
633 log_error(attach)("Failed to read request: v2 is unsupported ot disabled");
exact -> "exactly"
649 // Must contain exact 'buffer_size' bytes.
Also, is the line 631 comment, with 3 args, misleading? (moving away from exactly 3 arguments...)
Thanks!
-------------
PR Review: https://git.openjdk.org/jdk/pull/21888#pullrequestreview-2415229062
More information about the hotspot-runtime-dev
mailing list