Re: Fwd: read command sometimes misses newline on timeout

[Martin D Kealey]

On Tue, 8 Oct 2024 at 06:26, Greg Wooledge <greg@wooledge.org> wrote:

> From: *Thomas Oettli* <thomas.oettli@sfs.com>
> > The result is two lines in the buffer (without "\n" in between). Do you
> understand now what I mean?
>
> If bash is returning nonzero status after reading a full line, then that
> may be a bug that should be fixed.
> Martin may be looking into that.
>

Indeed I am.

At this point I'm reminded of Zork's Introduction: "*You are in a maze of
twisty little passages, all alike. You are likely to be eaten by a Gru.*"
Trying to track longjmp() through four translation units is like trying to
hunt a Gru that's always trying to sneak up behind me. (I'm beginning to
wonder if a Gru is a Gnu with the lights turned off.  If you don't hear
from me in a year, you'll know what to write on my epitaph.)

Just to be clear, I replicated this with strictly positive delays in the
millisecond range, so that it wouldn't ever use `read -t0`. Nor have I used
non-timed reads. The pattern still emerges, where in a small proportion of
cases SIGALRM gets delivered while *not* inside the `read` syscall, when
the `read` has consumed just the newline.

I've inserted code that, when "check_signals()" is called, will print out
where it was called from. The slightest shift in how I write the test as a
script dramatically changes the ratio of which lines are most active.

*Some* of my earlier tests output "TESTTESTTESTTESTTEST" (five-fold or
longer), indicating multiple successive lost newlines, but I didn't record
those sessions so I can't show you right now.

I'm about to add more code to tell me what the code was doing when the
signal was raised, as I suspect that will be more instructive than what's
happening when it's detected. (Yay, introspection in C. AAARGHH!*)

-Martin