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?