debugging - How do you track the source of an error? -

for panics, rust_backtrace=1 useful, doesn't non-fatal errors.

for example, have code ends with

match res {     ok(()) => (),     err(_) =>         println_err!("{:?}", res), } 

unfortunately, running in gdb doesn't whole lot default, since nothing exceptional happening. (ye olde c++ behavior unhandled exceptions call abort() , gdb break on sigabort default pretty convenient.)

next, since gdb supports reverse execution, thought debug setting breakpoint @ println_err line , reversing until found source of error.

(gdb) reverse-step target multi-thread not support command. 

a quick search revealed should like

(gdb) set libthread-db-search-path /etc/nonexistent (gdb) start 

but get

(gdb) reverse-step target child not support command. 

does mean reverse debugging isn't supported in rust? or doing wrong/suboptimal?

is there better solution manually go through each function forwarded error (with try!()) in order find out originated?

edit: making use of manual breakpoints , restarting, got point function returning, gdb can't seem tell return value is:

(gdb) finish run till exit #0  cafs::reader::reader::read_rawblock (self=0x7fffffffd628, h=sha256 = {...}) @ src/reader.rs:90 0x00005555556a096b in cafs::reader::reader::read_blockref_vec (self=0x7fffffffd628, r=reader = {...}) @ src/reader.rs:101 101             let raw = try!(self.read_rawblock(h)); value returned $3 = {union result<collections::vec::vec<u8>, std::io::error::error> (struct reader *, struct sha256)} 0x0 (gdb) 

so, maybe gdb not useful...

reverse debugging isn't easy reverse-step. have stop @ point before failure , ask gdb record. @ later point can reverse.

the built-in record facility on slow side. and, doesn't support multi-threading. it's difficult recommend beyond smallish use cases.

if you're serious pursuing reverse-debugging problem, let me recommend rr-project. it's better way approach this.