Debugging General

>>58569245
I'd like to get some experience using the crash utility to look at linux kernel dumps, but I don't have any real-world crashes.

>>58569292
just write a quick C program which has an overflow or a loop that goes out of bounds

do you have any advice for getting the same functionality of gdb out of lldb?

>>58569372
Well crash uses gdb under the hood.

https://people.redhat.com/anderson/crash_whitepaper/#WHY_CRASH

I've used the classic echo 1 /proc/sys/kernel/sysrq && echo 'c' | sudo tee /proc/sysrq-trigger to cause crashes, but I really want to find a crash dump where I don't already know what I'm looking for.

How does one (power user, not programmer), take advantage of debugging tools to determine and resolve problems/events?

I use strace right now to troubleshoot hanging programs (file access and fuse mounts), but gdb looks cool.

>>58569245
the visual studio debugger, while slow, is probably the best there is. I dont see one that come close to it on linux unfortunatly.

>>58569589
well i think the program would have needed to been compiled with debug flag so you might not be able to. it wouldn't hurt to try. in fact, you might get lucky and they accidentally ship a component of a huge software suite with debugging enabled. in that case you'll be quite able to exploit it since you'll have full access

GNU DEBUGGER

IS

HARD

>>58570925
Use DDD

>>58569245
pdb

>>58569483
get a usb to serial device. install the wrong driver on it, and it will crash your kernel

>>58571013
wrong driver for it* it will crash as soon as you plug it in

File: edb_bitch.png (431KB, 1920x1080px) Image search: [Google]

431KB, 1920x1080px

evans debugger here.
gdb a shit.

>>58570931
How the hell do you view source code while running?