rust-lldb: Incorrectly display Option::None as Option::Some

[zzjrabbit]

I am developing a kernel, and when I tried debugging with rust-lldb, I found this:

pm1b = Some({gas:{address_space:SystemMemory, bit_width:'\x99', bit_offset:'\0', access_size:'\0', address:234201088}, handler:(), mapping:Some({physical_start:18446603338569718192, virtual_start:{pointer:"APIC\x99"}, region_length:18446603338569718160, mapped_length:18446603336455397376, handler:()})}) {
    0 = {
      gas = {
        address_space = SystemMemory
        bit_width = '\x99'
        bit_offset = '\0'
        access_size = '\0'
        address = 234201088
      }
      handler =
      mapping = Some({physical_start:18446603338569718192, virtual_start:{pointer:"APIC\x99"}, region_length:18446603338569718160, mapped_length:18446603336455397376, handler:()}) {
        0 = {
          physical_start = 18446603338569718192
          virtual_start = {
            pointer = 0xffff80000df5a000 "APIC\x99"
          }
          region_length = 18446603338569718160
          mapped_length = 18446603336455397376
          handler =
        }
      }
    }
  }

While I unwrapped pm1b with the following code:

let pm1 = &registers.pm1_control_registers;
log::debug!("pm1: {:?}", pm1.pm1b.is_some());
loop {
    let pm1b = pm1.pm1b.as_ref();
    pm1b.unwrap().write((slp_typa | (1 << 13)) as u64).unwrap();
}

And there's the output.

[DEBUG] pm1: false, kernel_hal/src/platform/bare/acpi/power.rs:20
[ERROR] Panic: panicked at kernel_hal/src/platform/bare/acpi/power.rs:23:14:
called `Option::unwrap()` on a `None` value

What made me sure that this is a bug of rust-lldb is the length of the region, which is too large to be valid.
And I am using 1.95.0-nightly (ce69df6f7 2026-02-12) toolchain, while the version of lldb is 21.1.8 from nixpkgs.

[eggyal]

Smells like UB. Are you able to provide (hopefully minimized) example code that reproduces this error?

@rustbot label +A-debuggers-lldb +S-needs-repro

[zzjrabbit]

Sorry, I can't. My experiments all failed. But I managed to make lldb raise out a lot of errors. The basic idea is to write something like 0xfe to the flag byte of Option, and write meaningless bytes into the following regions. However, I can't see why such things can happen, due to the fact that the data in the origin issue is stored in the heap, and there's no unsafe operation that could have messed it up.

[eggyal]

write something like 0xfe to the flag byte of Option

But that causes undefined behaviour.

[zzjrabbit]

I just realized that it was in the heap, but after representing the number rust-lldb printed in hex, I found that it's not that meaningless, because it has something to do with the address the kernel was loaded. However, I still can't see why rust-lldb thought it was Option::Some.

[kpreid]

If the enum layout was “niche optimized”, then it is likely (but not guaranteed) that any value other than whatever was assigned to None would be treated as Some, at least as far as the compiled Rust code is concerned (I don't know how rust-lldb works). So, either rust-lldb is printing as accurately, or rust-lldb is printing invalid data as if it were valid data, but we don’t know without seeing the full definition of the type stored in the Option. Can you share it?

[zzjrabbit]

Yes. https://docs.rs/acpi/latest/acpi/address/struct.MappedGas.html

[workingjubilee]

@zzjrabbit

Sorry, I can't. My experiments all failed. But I managed to make lldb raise out a lot of errors. The basic idea is to write something like 0xfe to the flag byte of Option, and write meaningless bytes into the following regions. However, I can't see why such things can happen, due to the fact that the data in the origin issue is stored in the heap, and there's no unsafe operation that could have messed it up.

There is no guarantee that Option uses a "flag byte". The GenericAddress type that MappedGas contains this enum which would permit a niche optimization for any Option<MappedGas>: https://docs.rs/acpi/latest/acpi/address/enum.AddressSpace.html

Do not assume the layout of Option where it is not in the very limited set of guaranteed cases, as it may adopt radically different layouts based on T.