This is amazing!
🙏Thank you
Let me give this a try!
> From: Alex Matei <matei.alexandru@live.com>
> CC: Eli Zaretskii <eliz@gnu.org>, "45821@debbugs.gnu.org"
> <45821@debbugs.gnu.org>
> Date: Sun, 8 Jan 2023 16:00:27 +0000
>
> Okay, this was helpful, I was able to hit an access violation error on the 4th test
😊 -> only issue that now I
> need to get up to speed with GDB since it looks like WinDBG (which is my goto debugger, and also setup as
> postmortem for any process that fails on my machine, including Emacs) cannot read the symbols generated
> by the GCC compiler ☹
>
> * Soo, any tips on how to easily run the tests under debugger?
Easy:
cd /path/to/emacs/src
gdb ./emacs.exe
in GDB:
(gdb) run -Q
in Emacs:
M-x load-file RET ../test/lisp/net/network-stream-tests.el RET
M-x ert-run-tests-interactively RET THE-FAILING-TEST RET
where THE-FAILING-TEST is the name of the test which crashes. Then
wait for the crash, at which point GDB will kick in.
> * Or is there a way to set gdb to automatically launch whenever a crash happens in Emacs? -> this is
> what I typically do with WinDBG and it’s a pretty convenient feature
That is possible, but I don't recommend it: by the time the unhandled
exception will be thrown which starts GDB, it's too late: the original
crash was already converted into an unhandled exception, and you will
see in GDB a backtrace that has no traces of the code which actually
crashed.