Applying winpdb_reborn

[Chris Angelico]

On Sun, May 30, 2021 at 9:53 AM Rich Shepard <rshepard at appl-ecosys.com> wrote:
>
> On Sun, 30 May 2021, Chris Angelico wrote:
>
> > (Plus, there's not always an opportunity to use a debug harness. Sometimes
> > you just have to put your prints into production and let it run for two
> > weeks in the hope that the bug will show itself.)
>
> ChrisA,
>
> Please excuse my long-winded description of a FORTRAN IV bug in an lake
> ecosystem energy model I wrote at the University of Illinois in the early
> 1970s. It is an example of what you wrote above.
>
> The program fill two boxes of 80-column Hollerith cards punched on an IBM
> 29 (if I correctly recall the model) keypuch machine. The output was written
> on green-barred wide paper on a line printer.
>
> Each time I ran the model it would produce one of four different, but wrong,
> answers for one variable. I closely examined the 1.5" thick fan-folded line
> printer output many times. I never saw the error, even with diagnostic stubs
> added. When I took the output to the computer center they looked at it for a
> week and couldn't find the error, either.
>
> Shortly after that, when I again examined the code, line-by-line, I saw the
> error: a line that should have read
> FOR I=1 to N
> actually read
> FOR I=I to N
>
> All of us saw the uppercase I as a 1 because a) that's what we expected to
> see and b) line printer output on green-barred paper was not that clear,
> even with fresh ribbons.
>
> That lesson has stuck with me ever since.
>

Good lesson. And it's one of the things we really enjoy with modern
editing systems (IDEs, or just smart text editors) - we can use colour
to distinguish variable names from numeric literals!

Although that can sometimes get disrupted. The editor I use (SciTE)
will nicely syntax-highlight JavaScript code if it's in a .js file,
but if you're embedding a small amount of code inside a <script> block
in a .html file, it just highlights it as "this is a block of code"
rather than going for the full JS syntax highlighting (I can't really
fault it for that choice), meaning that sometimes there can be really
weird bugs lingering in those kinds of sections.

The description I gave was based on reality, too. Since we're swapping
stories of debugging, I'll expand on it.

I have a go-live tool for my Twitch streams. It's a web app written in
Python, and it uses OAuth2 to manage my stream configuration. During
initial development, it worked magnificently - everything was fine, it
worked as described, it's great! Then a couple of weeks later, it
just... bombed. Crashed out with an HTTP 500. I refreshed and it was
fine. Docketed the fault mentally and moved on. It behaved itself for
a while, but then, a few weeks later... bombed again. But it was just
another one-off.

Any attempt to run the code locally didn't trigger the bug. Any
attempt to push new code out to production also silenced the bug for a
while. It got to the point where, every time the bug showed itself,
I'd go in, adjust the print() calls, push to production again, and let
it sit there. I think it took something like four months to finally
track it down, one step every few weeks.

And what was the bug? I'd reused a variable name inside a function. It
was a fault of a refactor. The bug only came up every few weeks
because the only way to trigger it was an OAuth token refresh (not a
fresh login), and only if the refresh got triggered by a POST request.

I don't think any tool would have caught that. The only way to find it
was to put in print() calls - my usual slogan "If In Doubt, Print It
Out" (IIDPIO) wasn't sufficient, as I had to print out things that I
*wasn't* in doubt of. Tedious and frustrating, with every failed bug
probe leaving me even more bewildered.

Who else has really weird debugging stories? :)

ChrisA