1. 9
  1.  

  2. 8

    Could the title be re-worded, maybe as “Blizzard uses Visual Studio to debug Linux core dumps from the Diablo 4 server” ?

    1. 3

      Even our server programmers are most familiar with Windows development

      They run all their servers on Linux, but their server programmers are most familiar with Windows development? What? This really seems like a red flag to me.

      And like … your server is regularly core dumping, do the degree that you’re optimizing “how do we be good at our core dumps” and not “how do we do something other than dump core on errors”? Sorry, what? This whole thing seems extremely maladaptive to me.

      1. 4

        most important reason that we develop on Windows is the functionality and robust toolset provided by Visual Studio

        Did no one have the heart to tell them about JetBrain’s products?

        1. 3

          There is the option to remote login to the VM (or more specifically the container) that crashed and run gdb to diagnose the crash there. But there are numerous disadvantages to this. For one, we don’t deploy source with our binaries, so source is not available in a gdb session on a VM or container.

          Did no one have the heart to tell them about remote debugging?

        2. 1

          This was a very difficult article to parse. I think it should have been edited for clarity. For example:

          We develop our code on Windows and have a Windows version of our servers that can run under Windows.

          This would not have passed proofreading, the sentence is redundant. The rest of the article has similar problems.

          It would have been immensely more useful and clear if they provided code examples of their scripts in this pipeline.

          The script downloads the Docker container that was built with that version, extracts the server binary from it, along with certain shared runtime libraries for gdb’s use. (This avoids gdb compatibility problems you may encounter if your WSL version does not exactly match the deployed Linux version.) The script writes to ~/.gdbinit to set up the shared libraries as system libraries for the debug session.

          Couldn’t they just show the script? Omit any proprietary paths and just show the setup needed to get the right libstdc++.so extracted! I would have sent this article to my office, but it is too far from helpful.

          1. 2

            The script downloads the Docker container that was built with that version, extracts the server binary from it, along with certain shared runtime libraries for gdb’s use. (This avoids gdb compatibility problems you may encounter if your WSL version does not exactly match the deployed Linux version.) The script writes to ~/.gdbinit to set up the shared libraries as system libraries for the debug session.

            Couldn’t they just show the script? Omit any proprietary paths and just show the setup needed to get the right libstdc++.so extracted! I would have sent this article to my office, but it is too far from helpful.

            Recreating the script shouldn’t be to difficult, what I would do is something like this:

            • Use ldd to get a list of the libraries loaded by the program and copy all of these files
            • put these gdb commands a .gdbinit file (if solib-search-path doesn’t work right try something on this page instead https://sourceware.org/gdb/onlinedocs/gdb/Files.html)

            set solib-search-path /tmp/dbg/lib/

            file /tmp/dbg/executable

            core-file /tmp/dbg/core

            Also as an aise that setup they describe sounds a bit over-complicated, it would be much simpler if the “Debug on WSL” option worked with docker containers using the WSL backend (it might I haven’t tried yet).