Subject: bug#45821: Emacs UDP support on Windows

From: Alex Matei <[email-masked]>
Date: Sun, 8 Jan 2023 16:10:54 +0000

This is amazing! 🙏Thank you

Let me give this a try!

From: Eli Zaretskii<mailto:[email-masked]>
Sent: Sunday, January 8, 2023 8:08 AM
To: Alex Matei<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: bug#45821: Emacs UDP support on Windows

> From: Alex Matei <[email-masked]>
> CC: Eli Zaretskii <[email-masked]>, "[email-masked]"
>        <[email-masked]>
> 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.