4 ms·

One situation where I would have wanted a real debugger and couldn't use one was in crash reporting on remote systems (like, machine learning code running in so

by cknd 7y ago

One situation where I would have wanted a real debugger and couldn't use one was in crash reporting on remote systems (like, machine learning code running in some container somewhere, or on a headless box far from the network). Since Python's built-in tracebacks are pretty minimal, the default crash logs don't offer much help other than a line number. I ended up writing a tool that prints tracebacks along with code context and local variables [i], sort of a souped up version of the built-in crash message. It's surprising how much that already helped in a few situations, makes me wonder why it isn't the default. So, yes, more debuggers, but also abundant logging everywhere! [i] https://github.com/cknd/stackprinter https://github.com/cknd/stackprinter

Gibbon1 7y ago
Old school neckbeard way a) Crashes dump the program state to a file and then you load that in the debugger. b) If the process is still running but broken, attach the debugger. c) In my firmware I log bus fault addresses and restart. That allows me to see what code or memory access caused the error. 75% of the time it's fairly obvious what happened.
- int_19h 7y ago
  Crash dump debugging is tricky to implement Python, because its normal debugging APIs - sys.settrace, frame objects etc - require being inside the process with a running Python interpreter. You can still do it, but you basically have to redo the whole thing from scratch. For example, instead of asking for a repr() of an object to display its value, you have to access the internal representation of it directly - and then accommodate all the differences in that between various Python versions. Something like this (note several different dicts): https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa253583fefe3dbb320c87/Python/Product/Debugger.Concord/Proxies/Structs https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa2...
yoz 7y ago
Python's standard lib has had something like this for years, but it's been criminally under-promoted (probably because of the terrible name): https://docs.python.org/3/library/cgitb.html https://docs.python.org/3/library/cgitb.html However, yours provides much nicer output. Thank you!

by cknd 7y ago

Gibbon1 7y ago

Old school neckbeard way a) Crashes dump the program state to a file and then you load that in the debugger. b) If the process is still running but broken, attach the debugger. c) In my firmware I log bus fault addresses and restart. That allows me to see what code or memory access caused the error. 75% of the time it's fairly obvious what happened.

int_19h 7y ago
Crash dump debugging is tricky to implement Python, because its normal debugging APIs - sys.settrace, frame objects etc - require being inside the process with a running Python interpreter. You can still do it, but you basically have to redo the whole thing from scratch. For example, instead of asking for a repr() of an object to display its value, you have to access the internal representation of it directly - and then accommodate all the differences in that between various Python versions. Something like this (note several different dicts): https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa253583fefe3dbb320c87/Python/Product/Debugger.Concord/Proxies/Structs https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa2...

yoz 7y ago

Python's standard lib has had something like this for years, but it's been criminally under-promoted (probably because of the terrible name): https://docs.python.org/3/library/cgitb.html https://docs.python.org/3/library/cgitb.html However, yours provides much nicer output. Thank you!