1. 29

  2. 9

    This isn’t about debugging or UNIX for that matter. It’s about “normalization of deviance”, that one gets used to an incomplete, unfinished tool/feature/system, come to rely on it, and then something doesn’t work and isn’t transparent about “why”.

    Reminds of Ken Thompson’s “ed” editor’s sole error message - “?”. Because you should be able to figure out why on your own.

    So he’s right that UNIX is filled with the issue from the beginning, but he’s a bit obscure about the connection to the debugger. gdb is no different than ton’s of similar debuggers I’ve used for decades on systems unrelated to UNIX as well, so don’t blame it.

    If something refuses to function, there needs to be a means to say “hey, this part over here needs attention”. In this case, it’s like an uncaught exception, which is shorthand for “figure it out yourself”, i.e. back to Ken Thompson’s world as above.

    These things happen because someone doesn’t have the time or interest to finish the job. All kinds of software are left similarly uncompleted, because it works well enough to get the immediate job done, and the rest is quickly forgotten. Hardware examples abound, the the Pentium floating point errors, and like variants.

    1. 2

      I’m reminded of this presentation, aimed at language (in a very broad sense) designers about how to make better error messages.

      1. 1

        Thanks for that link. It is exactly what I needed at this time.

    2. 5

      GDB lives in a parallel universe where the framebuffer was never invented and we all still use teletype printers

      GDB has a built-in curses TUI. LLDB too, speaking of which, GDB is not the only debugger. LLDB is an excellent debugger. LLDB provides a C++ API for GUIs and other tools to use.

      1. 3

        Really great article. I am reminded of an older post “Taco Bell Programming”[1] that trolls a bit but does a good job of getting the Unix philosophy point across…and can easily lead to the dangers elaborated in this post.

        I have indeed committed the sin of parsing stdout and stderr in ways I should not have from programs that were not meant for such things. I have been bitten. But I wasn’t crazy enough to put it in production!


        1. 6

          I don’t see it that way. The author never makes a convincing case that Qt Creator hanging has anything to do with passing text between Qt Creator and gdb. You can pass error codes in any number of ways and you can set network timeouts even on command line tools. It seems like there was just an unfortunate bug in QtCreator that set him off on a rant.

          Also this:

          You see, on UNIX there’s GDB. That’s the debugger. That’s the only debugger. It’s very old and has had a lot of work put into it, and as a result it usually works pretty well, at least in terms of functionality. But on every other metric you measure software by, it kinda sucks.

          So by the metrics of completely being open source, costing 0 dollars, and supporting tons of targets, gdb “kinda sucks”?

          Despite every computer made in the past 40 years having a graphical display, GDB lives in a parallel universe where the framebuffer was never invented and we all still use teletype printers.

          gdb lives in a parallel universe where having a limited debug server that can run on lots of targets is really useful.

          1. 2

            I wasn’t arguing that point - gdb is a fine tool. My argument was a bit more general. There are many tools out there that don’t output in a way meant for automated consumption, and the output is subject to change at any moment because a contract was never declared. Unless formalized and specified outright and beforehand, text messages and log data is not an API and should not be treated as such. Those that write software around command line tools that don’t have output specifications available should be wary of using the tools that way. The strange thing as that as even though these tools are rewritten as open source in Linux and BSD, many go untouched and treated as black boxes. Why not crack open ssh and hook into lib calls instead? And if the code is not amenable to that, why not fork it and make it so?

            1. 3

              As mentioned by myfreeweb, GDB does have a full terminal interface (although enabling it is an obscure command I can never remember). Also, GDB has a documented protocol to communicate with it—they don’t parse the text output.

              The post is a rant about bad error reporting, but it doesn’t acknowledge that error reporting is both tedious and hard. For example, a routine to copy a file, given a source filename and a destination file name. First point of failure—can’t open the source file. Second point of failure—can’t open the destination file. Hard problem number 1—if the destination exists, is that an error? Or not? Do you allow the option to overwrite the destination? Okay, still can’t open the destination file, hard problem number two—you need to close the open source file (else you leak an open file descriptor), but the close can fail. If it fails, do you report that error? Or the original failure? Can the language you use even allow multiple error codes to be returned? Hard problem number three—how do you return which file had the error? Can your language do that? It doesn’t matter if your language just does return codes, or exceptions, it’s still the same issue—what if your exception handler throws an exception (and not via an explicit “throw”)?

              And I never did get to the actual copying of data either …