Provide a non-empty error callback to libbacktrace

[Aaron1011]

Currently, the error callback function passed to libbacktrace does nothing:

backtrace-rs/src/symbolize/libbacktrace.rs

Lines 156 to 158 in 190b2f9

	extern "C" fn error_cb(_data: *mut c_void, _msg: *const c_char, _errnum: c_int) {
	// do nothing for now
	}

Doing something here (printing an error, or just setting a flag that makes backtrace-rs calls fail) will make it much easier to debug issues like rust-lang/rust#69151 - it took me quite a while to realize that the memory corruption I was seeing was the result of libbacktrace intentionally freeing memory.

[Aaron1011]

It will be difficult to propagate any error that we catch, since functions like backtrace::resolve don't use Result.

@alexcrichton: What do you think about making backtrace::resolve take an FnMut(Result<&Symbol, SomeError>), or return an Result<(), SomeError>? It would make this library somewhat less ergonomic, but it would reflect the fact that some functions are not actually infallible.

[alexcrichton]

It's currently intentional that this library pretty aggresively ignores errors. Almost all usages of this are related to debugging where an error parsing dwarf or something like that shouldn't take down other tasks.

I'm open to the idea of exposing errors somehow but I haven't really thought about how it would be done or what it would look like. There's a lot of platforms and implementations to consider here, and I'm not sure if we can usefully and efficiently communicate errors for all the platforms.

[Aaron1011]

I think communicating the existence of an error (even it's a ZST on some platforms) would be an enormous improvement over reporting nothing at all. This would make it much easier to debug issues like rust-lang/rust#69151, since we'll know that something went wrong in libbacktrace itself.

[alexcrichton]

Er I don't mean to sound like I'm challenging the assumption that this is useful, only that implementing it "fully" may be quite difficult. Having a simple boolean bit would likely be much easier to implement and could be done relatively easily.