How can you expect people to debug something without posting the problematic code?
On Sun, 09 Nov 2025 05:59:33 -0700, Stan Marsh wrote: "Yes, this would all be easier if I made it into a standalone script instead of a function, but it is what it is and it won't be changed." Putting the code in a separate script would aid in debugging, since there would be a clear boundary between which code might be executing and which code is certain not to have executed. This idea seems obvious, but perhaps there's an issue in a for loop. Have you tried `kcov`? Wiley On Sun, Nov 9, 2025, 09:00 <[email protected]> wrote: > Send bug-bash mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/bug-bash > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bug-bash digest..." > > > Today's Topics: > > 1. Problems with running in non-monitor mode (Stan Marsh) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 09 Nov 2025 05:59:33 -0700 > From: Stan Marsh <[email protected]> > To: [email protected] > Subject: Problems with running in non-monitor mode > Message-ID: <[email protected]> > > (Yes, I had a bit of a hard time coming up with a Subject: title) > > And, yes, this is going to be short on "How to reproduce", because I can't > really tell > when/where it goes wrong and I don't really think I have the necessary > tools to debug it. > It also falls into the category of "Very few people ever run interactively > with job > control turned off, so this part of the code doesn't get exercised much, > so bugs don't get > found". > > That said, as I described in a previous post (either on bug-bash or > help-bash, not sure > which), I have a (rather long and complex) shell function that needs to > run with job > control turned off. Yes, this would all be easier if I made it into a > standalone script > instead of a function, but it is what it is and it won't be changed. > > Bash version is 5.3 and the platform is 32 bit Raspberry Pi. > > In the function, I do: set +m and I have traps setup so that on exit, it > does: set -m > > It all works fine until it (occasionally) stops working fine. After the > function has > exited back to the shell, I find I notice a bunch of weird behaviors in > the shell, such as > the keyboard freezing (until I hit ^C) and commands not doing anything > (e.g., I type in > "top" and it just returns to the prompt (see below)). > > The eventual fix is to do: exec $BASH, which re-initializes the shell and > things start > working again. > > And here's the really weird part. First note, I have "j" aliased to "jobs > -l". > See below; the output of "j" is really weird. It is not possible that I > have > started up 1780+ background jobs... (In fact, I haven't started *any* > background > jobs in this shell). But it looks like something in the function is > filling up > the jobs table and there doesn't seem to be any way to clean it out. > > --- Cut Here --- > $ j > [1783]- 6439 Stopped (tty output) continue > [1784] 6490 Done top > [1785]+ 6495 Done top > $ j > [1783]- 6439 Stopped (tty output) continue > [1784] 6490 Done top > [1785]+ 6495 Done top > $ %1783 > continue > $ j > [1784] 6490 Done top > [1785] 6495 Done top > $ %1784 > bash53: fg: job has terminated > Status: 1 > $ j > [1784] 6490 Done top > [1785] 6495 Done top > $ j > [1784] 6490 Done top > [1785] 6495 Done top > $ exec $BASH > ... > --- Cut Here --- > > Anyway, I am hoping that someone who has access to better debugging > tools than I do can figure out what is going on. It seems to be related > to running with job control turned off, but I can't be sure of that. > Note that I cannot post the actual function, as it is too complicated > and depends on too many things to be of use to anyone else. Sorry about > that. > > Note that I am not really looking for "fix this problem for me before 5PM" > type > help. I already have what seems like the only workable workaround > (re-exec'ing > the shell), but I am posting in the hope that some improvements can be > made in > the shell's code. > > > ================================================================================= > Please do not send me replies to my posts on the list. > I always read the replies via the web archive, so CC'ing to me is > unnecessary. > > When responding to my posts, please try to refrain from giving > bureaucratic answers. > If you have nothing useful to say, then just click Next and go on. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > bug-bash mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-bash > > > ------------------------------ > > End of bug-bash Digest, Vol 276, Issue 8 > **************************************** >
