8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 by dcubed-ojdk · Pull Request #6193 · openjdk/jdk

dcubed-ojdk · 2021-11-01T15:32:54Z

macOS12 has changed the dladdr() function to accept "-1" as a valid address and
we have functions that use dladdr() to convert DLL addresses into function or
library names. We also have a gtest that verifies that "-1" is not a valid value to use
as a symbol address.

As you might imagine, existing code that uses os::dll_address_to_function_name()
or os::dll_address_to_library_name() can get quite confused (and sometimes crash)
if an addr parameter of -1 was allowed to be used.

I've also made two cleanup changes as part of this fix:

In src/hotspot/os/bsd/os_bsd.cpp there is some macOS specific code that should
be properly #ifdef'ed. There is also some code that makes sense for ELF format
files, but not for Mach-O format files so that code needs to be excluded on macOS.
In src/hotspot/share/runtime/os.cpp I noticed a simple typo in a comment on an
#endif that I fixed. That typo does not appear anywhere else in the HotSpot code
base so I'd like to fix it with this bug ID since I'm in related areas.

This fix has been tested with Mach5 Tier[1-6].

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12

Reviewers

Thomas Stuefe (@tstuefe - Reviewer)
Gerard Ziemski (@gerard-ziemski - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6193/head:pull/6193
$ git checkout pull/6193

Update a local copy of the PR:
$ git checkout pull/6193
$ git pull https://git.openjdk.java.net/jdk pull/6193/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6193

View PR using the GUI difftool:
$ git pr show -t 6193

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6193.diff

dcubed-ojdk · 2021-11-01T15:33:05Z

/label add hotspot-runtime

dcubed-ojdk · 2021-11-01T15:33:23Z

/label add serviceability

bridgekeeper · 2021-11-01T15:34:32Z

👋 Welcome back dcubed! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-11-01T15:36:11Z

@dcubed-ojdk
The hotspot-runtime label was successfully added.

openjdk · 2021-11-01T15:37:40Z

@dcubed-ojdk
The serviceability label was successfully added.

mlbridge · 2021-11-01T15:40:37Z

Webrevs

01: Full - Incremental (ecb230d6)
00: Full (f57d7f0d)

dcubed-ojdk · 2021-11-03T16:21:44Z

Ping! Any takers?

tstuefe

Hi Daniel,

looks good. Small remarks below. I leave it up to you if you take my suggestions.

Cheers, Thomas

tstuefe · 2021-11-03T17:42:52Z

src/hotspot/os/bsd/os_bsd.cpp

+    // The Mach-O binary format does not contain a "list of files" with address
+    // ranges like ELF. That makes sense since Mach-O can contain binaries for
+    // than one instruction set so there can be more than one address range for
+    // each "file".


Small nit, it seems confusing to have a Mac-specific comment in the BSD section.

Maybe this would be better in MachDecoder? E.g. implement the 6-arg version of decode() but stubbed out returning false, and with your comment there.

It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS
port was built on top of the BSD port and the BSD port was built by copying a LOT
of code from Linux into BSD specific files with modifications as needed.

If I pushed this change down into MachDecoder, then I would have to lose the
ShouldNotReachHere() call in order to not assert in non-release bits. I don't
think I want to do that since this may not be the only place that calls the
6-arg version of decode().

It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS port was built on top of the BSD port and the BSD port was built by copying a LOT of code from Linux into BSD specific files with modifications as needed.

I always wondered whether anyone actually builds the BSDs in head. I assume Oracle does not, right? I know there are downstream porters somewhere but only for old releases, or?

If I pushed this change down into MachDecoder, then I would have to lose the ShouldNotReachHere() call in order to not assert in non-release bits. I don't think I want to do that since this may not be the only place that calls the 6-arg version of decode().

Fair enough, thanks for the clarification.

Oracle does not build BSD in head. At one point, Dmitry Samersoff used to build BSD
in his lab, but I don't know if he still does that.

tstuefe · 2021-11-03T17:49:40Z

src/hotspot/os/bsd/os_bsd.cpp

+      if (offset) *offset = -1;
+      return false;
+    }
+#endif


We use dladdr() in several places in this code. I wonder whether it would make sense to fix all of those with a wrapper instead:

static int my_dladdr(const void* addr, Dl_info* info) { if (addr != (void*)-1) { return dladdr(addr, info); } else { // add comment here return 0; } } #define dladdr my_dladdr

I'll take a look at the other calls to dladdr(). I'm trying to limit what I change
here to things that actually failed in our test on macOS12 on X64 and aarch64.

I took a quick look at the other calls to dladdr() in src/hotspot/os/bsd/os_bsd.cpp
and I'm not comfortable with changing those uses without having a specific test
case that I can use to investigate those code paths.

We are fairly early in our testing on macOS12 so I may run into a reason to revisit
this choice down the road.

I took a quick look at the other calls to dladdr() in src/hotspot/os/bsd/os_bsd.cpp and I'm not comfortable with changing those uses without having a specific test case that I can use to investigate those code paths.

We are fairly early in our testing on macOS12 so I may run into a reason to revisit this choice down the road.

Okay!

I've had a chance to think about this overnight and I'm not liking
my duplication of code so I'm going to look at adding a wrapper
that is called by the two calls sites where know I need the special
handling.

dcubed-ojdk

@tstuefe - Thanks for your review.

dcubed-ojdk · 2021-11-03T19:08:38Z

src/hotspot/os/bsd/os_bsd.cpp

+      if (offset) *offset = -1;
+      return false;
+    }
+#endif


I'll take a look at the other calls to dladdr(). I'm trying to limit what I change
here to things that actually failed in our test on macOS12 on X64 and aarch64.

dcubed-ojdk · 2021-11-03T19:19:11Z

src/hotspot/os/bsd/os_bsd.cpp

+    // The Mach-O binary format does not contain a "list of files" with address
+    // ranges like ELF. That makes sense since Mach-O can contain binaries for
+    // than one instruction set so there can be more than one address range for
+    // each "file".


It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS
port was built on top of the BSD port and the BSD port was built by copying a LOT
of code from Linux into BSD specific files with modifications as needed.

If I pushed this change down into MachDecoder, then I would have to lose the
ShouldNotReachHere() call in order to not assert in non-release bits. I don't
think I want to do that since this may not be the only place that calls the
6-arg version of decode().

gerard-ziemski

Looks good, just a few optional nitpicks that I personally would have done, if it were me doing the change.

gerard-ziemski · 2021-11-03T21:14:17Z

src/hotspot/os/bsd/os_bsd.cpp

+#endif

+#if defined(__APPLE__)


Why not just do:

#else

here instead and collapse these 3 lines into 1?

Hmmm... I'll take a look at doing that.

gerard-ziemski · 2021-11-03T21:17:45Z

src/hotspot/os/bsd/os_bsd.cpp

+#endif

+#if defined(__APPLE__)
+    char localbuf[MACH_MAXSYMLEN];


This __APPLE__ section is the only one, that I can see, using MACH_MAXSYMLEN, why not move:

#if defined(__APPLE__) #define MACH_MAXSYMLEN 256 #endif

here (i.e. just the #define MACH_MAXSYMLEN 256 and minimize the need for __APPLE__ sections?

Hmmm.... I'll take a look at cleaning this up a bit.

gerard-ziemski · 2021-11-03T21:22:30Z

src/hotspot/os/bsd/os_bsd.cpp

+    if (addr == (address)(intptr_t)-1) {
+      // dladdr() in macOS12/Monterey returns success for -1, but that addr
+      // value should not be allowed to work to avoid confusion.
+      buf[0] = '\0';
+      if (offset) *offset = -1;
+      return false;
+    }


Do we need this here? Wouldn't the earlier call to Decoder::decode(addr, localbuf, MACH_MAXSYMLEN, offset, dlinfo.dli_fbase)) catch this with ShouldNotReachHere?

That's the 5-parameter version of decode() and it doesn't have ShouldNotReachHere.

So if that code site is called and returns false, then we get into
dll_address_to_library_name() and reach this dladdr() call which
will accept the "-1"...

openjdk · 2021-11-04T05:14:35Z

@dcubed-ojdk This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12

Reviewed-by: stuefe, gziemski

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 85 new commits pushed to the master branch:

c393ee8: 8276632: Use blessed modifier order in security-libs code
7023b3f: 8276628: Use blessed modifier order in serviceability code
b933136: 8276641: Use blessed modifier order in jshell
0616d86: 8276635: Use blessed modifier order in compiler code
d95299a: 8276634: Remove usePlainDatagramSocketImpl option from the test DatagramChannel/SendReceiveMaxSize.java
3c0faa7: 8276173: Clean up and remove unneeded casts in HeapDumper
323d201: 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded
96c396b: 8276151: AArch64: Incorrect result for double to int vector conversion
7281861: 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416
8e17ce0: 8275185: Remove dead code and clean up jvmstat LocalVmManager
... and 75 more: https://git.openjdk.java.net/jdk/compare/b7104ba9a9006ab65e08ea9d7db22e72611ed07c...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

dcubed-ojdk

@tstuefe - Thanks for closing the loop on my previous replies.

@gerard-ziemski - Thanks for the review!

I'm going to make more tweaks to this fix and will update the
PR after my test cycle is complete.

dcubed-ojdk · 2021-11-04T17:17:34Z

src/hotspot/os/bsd/os_bsd.cpp

+      if (offset) *offset = -1;
+      return false;
+    }
+#endif


I've had a chance to think about this overnight and I'm not liking
my duplication of code so I'm going to look at adding a wrapper
that is called by the two calls sites where know I need the special
handling.

dcubed-ojdk · 2021-11-04T17:18:19Z

src/hotspot/os/bsd/os_bsd.cpp

+    // The Mach-O binary format does not contain a "list of files" with address
+    // ranges like ELF. That makes sense since Mach-O can contain binaries for
+    // than one instruction set so there can be more than one address range for
+    // each "file".


Oracle does not build BSD in head. At one point, Dmitry Samersoff used to build BSD
in his lab, but I don't know if he still does that.

dcubed-ojdk · 2021-11-04T17:19:25Z

src/hotspot/os/bsd/os_bsd.cpp

+#endif

+#if defined(__APPLE__)
+    char localbuf[MACH_MAXSYMLEN];


Hmmm.... I'll take a look at cleaning this up a bit.

dcubed-ojdk · 2021-11-04T17:20:09Z

src/hotspot/os/bsd/os_bsd.cpp

+#endif

+#if defined(__APPLE__)


Hmmm... I'll take a look at doing that.

dcubed-ojdk · 2021-11-04T17:25:21Z

src/hotspot/os/bsd/os_bsd.cpp

+    if (addr == (address)(intptr_t)-1) {
+      // dladdr() in macOS12/Monterey returns success for -1, but that addr
+      // value should not be allowed to work to avoid confusion.
+      buf[0] = '\0';
+      if (offset) *offset = -1;
+      return false;
+    }


That's the 5-parameter version of decode() and it doesn't have ShouldNotReachHere.

So if that code site is called and returns false, then we get into
dll_address_to_library_name() and reach this dladdr() call which
will accept the "-1"...

dcubed-ojdk · 2021-11-04T22:52:55Z

@tstuefe and @gerard-ziemski - please re-review when you get the chance.

dcubed-ojdk · 2021-11-04T22:54:58Z

This version has been tested with Mach5 Tier1 and with runs of the specific
tests using release and debug bits on macosx-aarch64 and macosx-x64
test machines running macOS12.

tstuefe

Looks good!

dcubed-ojdk · 2021-11-05T14:11:13Z

@tstuefe - Thanks for the re-review!

gerard-ziemski · 2021-11-05T14:49:45Z

Thank you Dan for the fix!

dcubed-ojdk · 2021-11-05T14:56:44Z

@gerard-ziemski - Thanks for the re-review!

dcubed-ojdk · 2021-11-05T17:02:51Z

/integrate

openjdk · 2021-11-05T17:04:53Z

Going to push as commit 92d2176.
Since your change was applied there have been 86 commits pushed to the master branch:

a74a839: 8276571: C2: pass compilation options as structure
c393ee8: 8276632: Use blessed modifier order in security-libs code
7023b3f: 8276628: Use blessed modifier order in serviceability code
b933136: 8276641: Use blessed modifier order in jshell
0616d86: 8276635: Use blessed modifier order in compiler code
d95299a: 8276634: Remove usePlainDatagramSocketImpl option from the test DatagramChannel/SendReceiveMaxSize.java
3c0faa7: 8276173: Clean up and remove unneeded casts in HeapDumper
323d201: 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded
96c396b: 8276151: AArch64: Incorrect result for double to int vector conversion
7281861: 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416
... and 76 more: https://git.openjdk.java.net/jdk/compare/b7104ba9a9006ab65e08ea9d7db22e72611ed07c...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-11-05T17:05:08Z

@dcubed-ojdk Pushed as commit 92d2176.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

dnadlinger · 2021-12-31T23:54:22Z

@dcubed-ojdk: I just ran into this in the Julia runtime and reached a similar conclusion/fix. Did you find out anything more about why this happens? At a glance, I didn't see any blatant addr == -1-style checks in the latest dyld open-source dump.

dcubed-ojdk · 2022-01-03T16:11:02Z

@dnadlinger - No I haven't chased this any further.

Also please see this note in the bug report:

https://bugs.openjdk.java.net/browse/JDK-8273967?focusedCommentId=14455403&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14455403

dnadlinger · 2022-01-05T06:21:15Z

@dcubed-ojdk: Thanks for taking the time to replyr regardless! The dlopen/dladdr/… man pages all show up fine on my machine, by the way (macOS 12.1).

8273967.cr0.patch

f57d7f0

dcubed-ojdk marked this pull request as ready for review November 1, 2021 15:35

openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Nov 1, 2021

openjdk bot added rfr Pull request is ready for review serviceability serviceability-dev@openjdk.org labels Nov 1, 2021

tstuefe reviewed Nov 3, 2021

View reviewed changes

dcubed-ojdk commented Nov 3, 2021

View reviewed changes

gerard-ziemski approved these changes Nov 3, 2021

View reviewed changes

tstuefe approved these changes Nov 4, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 4, 2021

dcubed-ojdk commented Nov 4, 2021

View reviewed changes

8273967.cr1.patch

ecb230d

tstuefe approved these changes Nov 5, 2021

View reviewed changes

gerard-ziemski approved these changes Nov 5, 2021

View reviewed changes

openjdk bot closed this Nov 5, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 5, 2021

dcubed-ojdk deleted the JDK-8273967 branch November 5, 2021 19:04

		#endif

		#if defined(__APPLE__)

		#endif

		#if defined(__APPLE__)

Conversation

dcubed-ojdk commented Nov 1, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

dcubed-ojdk commented Nov 1, 2021

Uh oh!

dcubed-ojdk commented Nov 1, 2021

Uh oh!

bridgekeeper bot commented Nov 1, 2021

Uh oh!

openjdk bot commented Nov 1, 2021

Uh oh!

openjdk bot commented Nov 1, 2021

Uh oh!

mlbridge bot commented Nov 1, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

dcubed-ojdk commented Nov 3, 2021

Uh oh!

tstuefe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcubed-ojdk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gerard-ziemski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Nov 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcubed-ojdk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

dcubed-ojdk commented Nov 1, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Nov 1, 2021 •

edited

Loading

openjdk bot commented Nov 4, 2021 •

edited

Loading

dnadlinger commented Dec 31, 2021 •

edited by bridgekeeper bot

Loading