You can also debug post-mortem with the minidump or the core dump file with WDT on Windows. Great fun and a good way to brush up on your assembly skills
That’s not true though. You can get the backtrace and other useful information from the coredump mentioned by the error message by loading it with gdb. Not as good as attaching it to a living process, since you can’t see step-by-step what happens leading up to the error, but still quite useful.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
The developer must either provide the logging and attach a debugger or go get fucked when a runtime error happens
You can also debug post-mortem with the minidump or the core dump file with WDT on Windows. Great fun and a good way to brush up on your assembly skills
Just load it on the debugger and leave your asm skill gather patina.
are you c++?
That’s not true though. You can get the backtrace and other useful information from the coredump mentioned by the error message by loading it with gdb. Not as good as attaching it to a living process, since you can’t see step-by-step what happens leading up to the error, but still quite useful.
Well yes, that’s a pretty good way of debugging a third party app but if you are developing something you can have more ease with gdb attached