On Tue, 8 Oct 2024 at 06:26, Greg Wooledge <g...@wooledge.org> wrote:
> From: *Thomas Oettli* <thomas.oet...@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
