endoli / endoli/lldb.rs

bug: `SBSymbol.name` and `SBFrame.disassemble` crash on null pointer

Open
#40 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
62
Forks
15
PR merge metrics
No merged PRs in 30d

Description

Crate Version: "0.0.12"
OS: MacOS Sequoia 15.0.1

This is similar to #37 but affecting other functions.

I've observed crashes for both `SBSymbol.name` and `SBFrame.disassemble` when the underlying `SBSymbolGetName` and `SBFrameDisassemble` calls return a null pointer.

I tried finding lldb documentation on why `GetName` or `Disassemble` would ever return `null` but wasn't able to find a concrete answer. `is_valid` does return `false` though.

In my case this happened after stepping an instruction after `svc` instruction to trigger `exit` sys call.

Sample rust script

```rust
use lldb::SymbolType;
use lldb::sys;
use lldb::{LaunchFlags, SBDebugger, SBLaunchInfo};

fn main() {
SBDebugger::initialize();

let debugger = SBDebugger::create(false);
debugger.set_asynchronous(false);
println!("{debugger:?}");

if let Some(target) = debugger.create_target_simple("../lang") {
println!("{target:?}");

let launchinfo = SBLaunchInfo::new();
launchinfo.set_launch_flags(LaunchFlags::STOP_AT_ENTRY);
match target.launch(launchinfo) {
Ok(process) => {
println!("running {process:?}");
let symbols = target.find_symbols("start", SymbolType::Any);
let symbol = &symbols.iter().next().unwrap().symbol();
let address = symbol.start_address().unwrap();

let breakpoint = target.breakpoint_create_by_sbaddress(address);

let thread = process.threads().next().unwrap();

process.continue_execution();

let thread = process.threads().next().unwrap();

while let Ok(()) = thread.step_instruction(false) {
println!("\n\n==New Frame==");
let frame = thread.selected_frame();

let symbol = frame.symbol();

let symbol_raw = symbol.raw;
println!("raw: {:?}", symbol_raw);

let name = unsafe { sys::SBSymbolGetName(symbol_raw) };
println!("symbol ptr {:?}", name); // this is null for that last frame

println!("symbol: {}", symbol.name()); // segfault

let diss = frame.disassemble();
println!("{}", diss);
}

println!("done {process:?}");
}
Err(e) => println!("Uhoh: {e:?}"),
}
}
SBDebugger::terminate();
}
```

Sample output

```
SBDebugger { Debugger (instance: "debugger_1", id: 1) }
SBTarget { main }
running SBProcess { SBProcess: pid = 96004, state = stopped, threads = 1, executable = main }

==New Frame==
raw: 0x600001a48400
symbol ptr 0x14b0f3210
symbol: start
main`start:
0x10493fee0 <+0>: mov x0, #0x0 ; =0
-> 0x10493fee4 <+4>: mov x16, #0x1 ; =1
0x10493fee8 <+8>: svc #0x80

==New Frame==
raw: 0x600001a500a0
symbol ptr 0x14b0f3210
symbol: start
main`start:
0x10493fee0 <+0>: mov x0, #0x0 ; =0
0x10493fee4 <+4>: mov x16, #0x1 ; =1
-> 0x10493fee8 <+8>: svc #0x80

==New Frame==
raw: 0x600001a50090
symbol ptr 0x0
[1] 95898 segmentation fault cargo run
```

Program being debug

Was just debugging an aarch64 assembly program for MacOS which unfortunately might not be that portable for reproduction but all it does is call the `exit` sys call with status code of 0.

```arm
.global _start
.align 4

_start:
start:
mov x0, #0
mov x16, #1
svc #0x80

```

Compilation:
```
as -g main.s -o main.o
ld -o main -lSystem -syslibroot `xcrun -sdk macosx --show-sdk-path` -e _start -arch arm64 main.o
```

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.