Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7565] LLDB print fails to unmask extra inhabitants in enums #4371

Closed
zwaldowski opened this issue Apr 29, 2018 · 7 comments
Closed

[SR-7565] LLDB print fails to unmask extra inhabitants in enums #4371

zwaldowski opened this issue Apr 29, 2018 · 7 comments
Assignees
Labels
bug Something isn't working LLDB for Swift

Comments

@zwaldowski
Copy link

Previous ID SR-7565
Radar rdar://39869332
Original Reporter @zwaldowski
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Apple Swift version 4.1.1 (swiftlang-902.0.50 clang-902.0.39.1)
Xcode Version 9.3 (9E145)
macOS 10.13.4 (17E202)

Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug
Assignee @dcci
Priority Medium

md5: d1b8968f72279b4b25fc63113511b141

Issue Description:

See attached file.

A type contains a non-generic multipayload enum, two of which have associated values. On Darwin, this enum lays out its discriminator using spare bits. The printer of LLDB doesn't unmask these properly, yielding invalid subsequent children.

If you breakpoint where indicated in the attached file, and `p x` and `p y`, you'll see this:

(lldb) p x
(Debug.A) $R0 = {
{{ variant = x {}}
{{ x = 0x0000000100e4a950 (xx = 42)}}
{{ }}}
{{}}}
(lldb) p y
(Debug.A) $R1 = {
{{ variant = y {}}
{{ y = 0x4000000100e4c580 (yy = Swift.Int @ )}}
{{ }}}
{{}}}

Notice "0x4" at the start of `y` and how it can't read the memory for `yy`.

@belkadan
Copy link

belkadan commented May 1, 2018

jingham@apple.com (JIRA User), @dcci, is there a dup of this?

@dcci
Copy link
Mannequin

dcci mannequin commented May 1, 2018

Looking!

@dcci
Copy link
Mannequin

dcci mannequin commented May 1, 2018

@swift-ci create

@dcci
Copy link
Mannequin

dcci mannequin commented May 1, 2018

This reproduces on top-of-tree lldb.

(lldb) p y
(blah.A) $R2 = {
  variant = y {
    y = 0x4000000100a00350 (yy = Swift.Int @ )
  }
}
(lldb) frame var y
(blah.A) y = {
  variant = y {
    y = 0x4000000100a00350 (yy = Swift.Int @ )
  }
}

It's not `expr` being broken (only), as this also shows up in the `frame var` path. I'll investigate further. Thanks for your report!

@dcci
Copy link
Mannequin

dcci mannequin commented May 1, 2018

(lldb) frame var --raw y
(blah.A) y = {
variant = y {
 x = 0x4000000100a00240 {
   xx = {
     _value = <read memory from 0x4000000100a00250 failed (0 of 8 bytes read)>

   }
 }
 y = 0x4000000100a00240 {...}
}
}

And `log types`:

                 ADT-style enum - inspecting data to find enum case for type Variant
                 tag_bits        = 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011
                 current_payload = 0000 1011 0000 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0000 0000 0010
                 discriminator value of 1 acceptable, case y matched
                 C-style enum - inspecting data to find enum case for type Variant
                 m_nopayload_elems_bitmask        = 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111
                 current_payload                  = 0000 1011 0000 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0000 0000 0010
                 masked current_payload           = 0000 1011 0000 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0000 0000 0010
                 bitmask search failed
                 ADT-style enum - inspecting data to find enum case for type Variant
                 tag_bits        = 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011
                 current_payload = 0000 1011 0000 0000 0000 0011 0000 0000 1000 0000 0000 0000 0000 0000 0000 0010
                 discriminator value of 1 acceptable, case y matched
                 [MemoryReader] asked to read 8 bytes at address 0x4000000100c000d0
                 [MemoryReader] memory read returned fewer bytes than asked for
                 could not read heap metadata for object at 4611686022734938320: an unknown failure occurred

@dcci
Copy link
Mannequin

dcci mannequin commented May 2, 2018

This is going to be tricky to fix for the general case, I had a discussion with Slava about it.

Possible solutions:

  1. if you can run code in the target, there are value witness functiosn for each enum type to proejct the tag number and project a payload
  2. if you can't run code, you'd have to simulate what those functions are doing, which is hard, but it will be easier once we store a declarative description somewhere for reflection to use

Currently mirrors and RemoteAST don’t support enums. So, this turns out to be a fair bif ot work.

@dcci
Copy link
Mannequin

dcci mannequin commented Dec 19, 2018

Fixed in: apple/swift-lldb#1165

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

2 participants