Floating point exception when debugging with lldb on Mac OS X

[swgillespie]

Here's an interesting issue I've encountered when debugging - Option<char> seems to trigger a floating point exception in LLDB.

Environment details:

• Mac OS X 10.10.5
• rustc: rustc 1.5.0-nightly (eafe106ef 2015-10-15)
• lldb: lldb-330.0.44

Repro steps:

• Create a file dwarf.rs, with the following contents:

fn main() {
    let c = thing_with_char('\n');
    println!("{:?}", c);
}

fn thing_with_char(c: char) -> Option<char> {
    thing_with_option_char(c)
}

fn thing_with_option_char(c: char) -> Option<char> {
    Some(c)
}

• Compile it with debug info:

rustc -g dwarf.rs -o dwarf

• Run dwarf and see it has the correct output:

$ ./dwarf
Some('\n')

• Run dwarf under LLDB, set a breakpoint on thing_with_char, start the program, and step once:

$ lldb ./dwarf
(lldb) target create "./dwarf"
Current executable set to './dwarf' (x86_64).
(lldb) b thing_with_char
Breakpoint 1: where = dwarf`dwarf::thing_with_char + 15 at dwarf.rs:7, address = 0x000000010000148f
(lldb) r
Process 38743 launched: './dwarf' (x86_64)
error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32
Process 38743 stopped
* thread #1: tid = 0x15343, 0x000000010000148f dwarf`dwarf::thing_with_char(c=<unavailable>) + 15 at dwarf.rs:7, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000010000148f dwarf`dwarf::thing_with_char(c=<unavailable>) + 15 at dwarf.rs:7
   4    }
   5
   6    fn thing_with_char(c: char) -> Option<char> {
-> 7        thing_with_option_char(c)
   8    }
   9
   10   fn thing_with_option_char(c: char) -> Option<char> {
(lldb) n
Floating point exception: 8

The result is a floating point exception. The error message

error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32

makes it sound like this is DWARF-related. Also, the Option seems to be a crucial detail - this is what triggers the behavior in my program where I ran into this and also in this repro here.

LLDB's stack trace:

* thread #9: tid = 0x15ee6, 0x0000000101e0c341 LLDB`ExtractBytesFromRegisters(lldb_private::ExecutionContext&, lldb_private::ClangASTType&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb::ByteOrder, std::__1::shared_ptr<lldb_private::DataBuffer>&, unsigned int, unsigned int&, unsigned int&, bool&) + 1279, stop reason = EXC_ARITHMETIC (code=EXC_I386_DIV, subcode=0x0)
  * frame #0: 0x0000000101e0c341 LLDB`ExtractBytesFromRegisters(lldb_private::ExecutionContext&, lldb_private::ClangASTType&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb::ByteOrder, std::__1::shared_ptr<lldb_private::DataBuffer>&, unsigned int, unsigned int&, unsigned int&, bool&) + 1279
    frame #1: 0x0000000101e0c055 LLDB`ExtractBytesFromRegisters(lldb_private::ExecutionContext&, lldb_private::ClangASTType&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&, lldb::ByteOrder, std::__1::shared_ptr<lldb_private::DataBuffer>&, unsigned int, unsigned int&, unsigned int&, bool&) + 531
    frame #2: 0x0000000101e0bb0a LLDB`ABISysV_x86_64::GetReturnValueObjectImpl(lldb_private::Thread&, lldb_private::ClangASTType&) const + 1166
    frame #3: 0x0000000101d4ebac LLDB`lldb_private::ABI::GetReturnValueObject(lldb_private::Thread&, lldb_private::ClangASTType&, bool) const + 84
    frame #4: 0x0000000101d9ad1a LLDB`lldb_private::ThreadPlanStepOut::CalculateReturnValue() + 202
    frame #5: 0x0000000101d9abb7 LLDB`lldb_private::ThreadPlanStepOut::DoPlanExplainsStop(lldb_private::Event*) + 415
    frame #6: 0x0000000101d96568 LLDB`lldb_private::ThreadPlan::PlanExplainsStop(lldb_private::Event*) + 40
    frame #7: 0x0000000101d8f019 LLDB`lldb_private::Thread::ShouldStop(lldb_private::Event*) + 765
    frame #8: 0x0000000101d94cc4 LLDB`lldb_private::ThreadList::ShouldStop(lldb_private::Event*) + 488
    frame #9: 0x0000000101d66741 LLDB`lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) + 379
    frame #10: 0x0000000101d63d44 LLDB`lldb_private::Process::HandlePrivateEvent(std::__1::shared_ptr<lldb_private::Event>&) + 356
    frame #11: 0x0000000101d66e81 LLDB`lldb_private::Process::RunPrivateStateThread() + 511
    frame #12: 0x0000000101d66935 LLDB`lldb_private::Process::PrivateStateThread(void*) + 9
    frame #13: 0x00007fff92d6605a libsystem_pthread.dylib`_pthread_body + 131
    frame #14: 0x00007fff92d65fd7 libsystem_pthread.dylib`_pthread_start + 176
    frame #15: 0x00007fff92d633ed libsystem_pthread.dylib`thread_start + 13

This could very well be a bug in lldb - it does look like it's dividing by zero.

[r-52]

I'm facing the same issue with rustc 1.3.0. Chars triggers the exception in my code using OS X 10.11 and lldb-340.4.70.
If I put a breakpoint on the next line, after some code that worked with Chars, lldb won't stop with the exception - only if I step over the line.

[sfackler]

I ran into this as well. It may be a newly introduced LLDB bug since it's suddenly popped up?

[swgillespie]

Following up on this - I built from the tip of LLDB the other day and the issue did not reproduce, so this is definitely an LLDB issue but one that has been fixed recently. I don't know how recent the fix was, but at least the bleeding edge works.

Anybody else who runs into this issue - updating LLDB might help, or if it doesn't, building it from source does.

[sfackler]

This is still happening on lldb-360.1.70 - I'm assuming that it's been long enough that whatever fixes were in the LLDB repo a year and a half ago would have propagated by now?

~ ❯ rust-lldb foo
(lldb) command source -s 0 '/tmp/rust-lldb-commands.jrvqZH'
Executing commands in '/tmp/rust-lldb-commands.jrvqZH'.
(lldb) command script import "/Users/sfackler/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/etc/lldb_rust_formatters.py"
(lldb) type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
(lldb) type category enable Rust
(lldb) target create "foo"
Current executable set to 'foo' (x86_64).
(lldb) b thing_with_char
Breakpoint 1: where = foo`foo::thing_with_char + 11 at foo.rs:6, address = 0x000000010000178b
(lldb) r
Process 60614 launched: '/Users/sfackler/foo' (x86_64)
error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32
Process 60614 stopped
* thread #1: tid = 0x40bc67, 0x000000010000178b foo`foo::thing_with_char(c=<unavailable>) + 11 at foo.rs:6, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000010000178b foo`foo::thing_with_char(c=<unavailable>) + 11 at foo.rs:6
   3   	    println!("{:?}", c);
   4   	}
   5
-> 6   	fn thing_with_char(c: char) -> Option<char> {
   7   	    thing_with_option_char(c)
   8   	}
   9
(lldb) n
Process 60614 stopped
* thread #1: tid = 0x40bc67, 0x0000000100001791 foo`foo::thing_with_char(c=<unavailable>) + 17 at foo.rs:7, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x0000000100001791 foo`foo::thing_with_char(c=<unavailable>) + 17 at foo.rs:7
   4   	}
   5
   6   	fn thing_with_char(c: char) -> Option<char> {
-> 7   	    thing_with_option_char(c)
   8   	}
   9
   10  	fn thing_with_option_char(c: char) -> Option<char> {
(lldb) n
/Users/sfackler/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rust-lldb: line 41: 60612 Floating point exception: 8   lldb --source-before-file="$TMPFILE" "$@"
~ ❯ lldb --version
lldb-360.1.70

[sfackler]

I can't get a stack trace of LLDB due to SIP unfortunately :(

[aturon]

cc @rust-lang/compiler, in case anyone can provide help.

[jasonwilliams]

Hey @aturon @swgillespie, i've been getting errors in my debugger within vscode, and i think this issue is the root cause.

I can still reproduce this issue, so let me know if i can help get this resolved.
vadimcn/codelldb#127

Rustc:rustc 1.28.0 (9634041f0 2018-07-30)
LLDB:lldb-900.0.45
MacOS: 10.13.6

Steps To Replicate

• Clone https://github.com/jasonwilliams/boa
• cargo build the project
• lldb target/debug/bin
  --Inside LLDB--
• b lex
• r
• frame variable

[nrc]

cc @tromey DO you know what might be going on here?

[tromey]

Not offhand but it's worth trying the lldb from rustup (if it's available now, I haven't been able to check). If that still fails, I will take a look when I'm better.

[tromey]

@jasonwilliams boa didn't build for me with stable rust. Is there some particular revision I could try?

[jasonwilliams]

@tromey sorry about that, i was developing on it, it should build now.
How do i use lldb from rustup? Ive been using rust-lldb which gives a similar error

[tromey]

How do i use lldb from rustup?

Currently it isn't very easy; you can try adding the lldb component to nightly but you'll have to dig around in ~/.rustup/toolchains to find the executable (this is being fixed in #53973 and/or #48168).

[tromey]

With my rust-enabled lldb on macOS, I get:

(lldb) frame var
(&mut js::syntax::lexer::Lexer) self = 0x00007ffeefbff4d0

I'm not sure if this is due to the rust plugin or just general lldb bug fixes.

[jasonwilliams]

@tromey sorry bit confused, is that it working properly?
Even if this works properly with rust-lldb, how would my text editor (vscode) make use of this, as i think that looks for lldb in the system PATH

this is what i get, using normal lldb from MacOS

(lldb) frame variable
error: bin DWARF DIE at 0x0001302f (class Option<char>) has a member variable 0x00013036 (RUST$ENCODED$ENUM$0$None) whose type is a forward declaration, not a complete definition.
Try compiling the source file with -fno-limit-debug-info
error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32
Illegal instruction: 4

if this is an LLDB bug what do we do?
cc @rust-lang/compiler

[tromey]

error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32

The C++ language plugin for lldb only handles a specific subset of possible DWARF scalar encodings. In particular for DW_ATE_unsigned_char it only handles 8-bit and 16-bit (well, it checks for short) character types. Switching to DW_ATE_UTF (which I plan to do eventually) won't help because lldb checks for the names char16_t and char32_t.

The rust-enabled lldb doesn't have this problem. However, at the moment you can't easily install it (we need a rustup fix to ship first).

@tromey sorry bit confused, is that it working properly?

Sorry about the delay. I missed your question. Yes, that was the rust-enabled lldb working properly, I believe.

if this is an LLDB bug what do we do?

I think the route forward is to get the rust-enabled lldb shipping. This will insulate us from mismatches between what the clang plugin for lldb expects and what the rust compiler emits.

Another possibility is patching lldb upstream. This might be worthwhile.

Another idea would be to emit the rust char type with the name char32_t, but I would really prefer not to do that. This would work around an lldb bug at the expense of both ugliness and requiring a hack in gdb to undo the damage there.

[tromey]

If you're interested in the lldb code it is in source/Symbol/ClangASTContext.cpp, see ClangASTContext::GetBuiltinTypeForDWARFEncodingAndBitSize.

[tromey]

Even if this works properly with rust-lldb, how would my text editor (vscode) make use of this, as i think that looks for lldb in the system PATH

I missed this question earlier, sorry!

I don't know the answer, but we had a discussion about deploying the rust-enabled lldb here: rust-lang/rustup#1492

There you can see that the conclusion was to modify rust-lldb to preferentially launch the rust-enabled lldb if it is found.

Maybe your editor can be patched? The thing is, if you're truly locked in to only running the system lldb, then you are just going to lose out, because upstream lldb does not want to merge the rust plugin (it's more complicated than that but it's true enough for now).

[jasonwilliams]

Thanks @tromey
I've spoken to the vscode-lldb plugin maintainers and there is an option to point to any binary we want, so lock-in shouldn't be an issue.

Am i right in thinking that once this is closed (#48168) i can point my editor to rust-lldb ?

[jasonwilliams]

I can confirm this works without crashing using rust-lldb.
I installed rustup component add lldb-preview --toolchain nightly
Then i set "lldb.executable": "rust-lldb" in VSCode now all works

[tromey]

I think this is solved, so I am closing it.