$PPID behave differently in 5.1 and 4.3

[leodream]

I created 2 scripts like below
 

Running the test1.sh with bash 5.1 will have different PPID printed by the
last test2.sh call when it is executed in sub-shell.
For bash 4.3, the script will output consistent PPID.
  


It looks like something had been changed regarding the sub-shell execution
in later Bash versions?




--
Sent from: http://gnu-bash.2382.n7.nabble.com/

Re: Possible regression in 'wait' command

[Chet Ramey]

On 5/13/21 3:44 PM, Jonas Alfredsson via Bug reports for the GNU Bourne 
Again SHell wrote:



Bash Version: 5.1
Patch Level: 0
Release Status: release

Description:
If one has a script similar to this:

```bash
trap 'echo "Received SIGHUP"' HUP

sleep 5m &
child_pid=$!

wait -n ${child_pid}
wait -n ${child_pid}
```

and you send in the system signal SIGHUP the first `wait` will exit (as 
expected)
and the message "Received SIGHUP" will be printed. However, since we have a
second `wait` it should catch further execution and wait for the child once 
again.


Thanks for the report. The issue is a change between bash-5.0 and bash-5.1
to understand PID arguments with -n. The job state wasn't restored upon
receipt of all trapped signals and interfered with subsequent calls to
`wait -n'.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: $PPID behave differently in 5.1 and 4.3

[Eduardo Bustamante]

On Sun, May 16, 2021 at 1:38 AM leodream  wrote:
>
> I created 2 scripts like below
> 
>
> Running the test1.sh with bash 5.1 will have different PPID printed by the
> last test2.sh call when it is executed in sub-shell.
> For bash 4.3, the script will output consistent PPID.
> 
>
>
> It looks like something had been changed regarding the sub-shell execution
> in later Bash versions?

Yes. See the following entries in the 5.1 changelog
(https://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES-5.1?h=88bdb448b40b81a8dc1b8c2682bb5bb968d8213b#n134):

$ grep optimize CHANGES-5.1
c. Bash attempts to optimize away forks in the last command in a function body
b. Bash attempts to optimize the number of times it forks when executing

What you're seeing is that bash notices that it can optimize the
function call by avoiding a fork when calling "test2.sh" the third
time, thus the parent PID is different. This is done by the
`optimize_shell_function` in builtins/evalstring.c.


By the way, in the future, avoid sending scripts as screenshots and
instead just send them as plain text.  It makes it more difficult for
us to help you because now we have to transcribe your code from a
picture and hope that we didn't make any mistakes along the way.

Re: Possible regression in 'wait' command

[Jonas Alfredsson]

Hi Robert,

Thank you for your response.

> Don't use non standard command extensions
> in test scripts like this.

Apologies, this is my first reported issue for Bash,
so this was just a number I used to have plenty of
time when experimenting by myself. I will keep this in
mind in the future.

> I tested with the following script [...]

That is a much more compact version of what I came
up with, really nice! I will see if I can add this to
my repository where, through Docker, you can test out
both versions of Bash if you like.


I am a little bit unsure of how this mailing list works,
if everyone gets every mail, but I also got a response
from Chet Ramey, whom I will ask how we best move forward
in perhaps getting this fixed.

Best regards
Jonas



‐‐‐ Original Message ‐‐‐
On Friday, May 14, 2021 5:45 AM, Robert Elz  wrote:

> Date: Thu, 13 May 2021 23:52:20 +0200
> From: Alex fxmbsw7 Ratchev fxmb...@gmail.com
>
> Message-ID:  
> 
>
>
> |https://www.ibm.com/support/pages/exit-code-127-means-jobs-command-can-not-be-found-or-executed
>
> I have no idea what info that reply was
> intended to add, but it us not useful.
>
> | On Thu, May 13, 2021, 23:10 Jonas Alfredsson via Bug reports for the GNU
> | Bourne Again SHell bug-bash@gnu.org wrote:
> | > If one has a script similar to this:
>
> | > trap 'echo "Received SIGHUP"' HUP
> | >
> | > sleep 5m &
>
> Don't use non standard command extensions
> in test scripts like this. If you cannot
> work out the number of seconds in 5 mins
> you can use $(( 5 * 60 )) but that is really
> too long. 60 secs is plenty, 20 would do.
>
> | > child_pid=$!
> | >
> | > wait -n ${child_pid}
> | > wait -n ${child_pid}
>
> | > and the message "Received SIGHUP" will be printed. However, since we have 
> a
> | > second `wait` it should catch further execution and wait for the child
> | > once again.
>
> Yes, it should, assuming you send the HUP to
> the shell pid, and not to the process group
>
> | > This is how it works in Bash 5.0.x,
>
> I no longer have one of those to test, but
> I do have bash 4, and it worked there too.
>
> | > Unfortunatly I do not know the low level stuff well enough to
> | > even know where to begin debugging this,
>
> Start by sprinkling jobs -l commands
> at relevant places, that confirms that
> the sleep command is still running and
> still hasan entry in the jobs table.
>
> I tested with the following script
>
> trap 'echo "Received SIGHUP"' HUP
>
> sleep 60 &
> child_pid=$!
>
> jobs -l
> wait -n ${child_pid}
> echo wait1 $?
> jobs -l
> wait -n ${child_pid}
> echo wait2 $?
> jobs -l
>
> and ran that as
>
> bash -x /tmp/b & sleep 5; kill -1 $!
>
> That shows the issue clearly.
>
> My guess is that perhaps the first wait
> command is setting some state on the job
> indicating it has been waited upon, which
> is not being cleared when that wait aborts.
>
> But that is just a guess, I have not looked
> at the bash code.
>
> kre

Re: Possible regression in 'wait' command

[Jonas Alfredsson]

Hi Chet,

Thank you for the response.
If I read it correctly you agree that this is a regression from how
it worked previously?

I am not a very experienced C programmer, so I am a little bit hesitant
to dive into the code to try to fix it myself. However, I am not certain
on how to proceed from here. Would you like me to try to see if I can
figure out a solution, or is this better handled in a more organized way by
people with the appropriate know how?

Best regards
Jonas


‐‐‐ Original Message ‐‐‐
On Sunday, May 16, 2021 6:46 PM, Chet Ramey  wrote:

> On 5/13/21 3:44 PM, Jonas Alfredsson via Bug reports for the GNU Bourne
> Again SHell wrote:
>
> > Bash Version: 5.1
> > Patch Level: 0
> > Release Status: release
> > Description:
> > If one has a script similar to this:
> >
> > trap 'echo "Received SIGHUP"' HUP
> >
> > sleep 5m &
> > child_pid=$!
> >
> > wait -n ${child_pid}
> > wait -n ${child_pid}
> >
> >
> > and you send in the system signal SIGHUP the first `wait` will exit (as 
> > expected)
> > and the message "Received SIGHUP" will be printed. However, since we have a
> > second `wait` it should catch further execution and wait for the child once 
> > again.
>
> Thanks for the report. The issue is a change between bash-5.0 and bash-5.1
> to understand PID arguments with -n. The job state wasn't restored upon
> receipt of all trapped signals and interfered with subsequent calls to
> `wait -n'.
>
> Chet
>
> -
>
> `The lyf so short, the craft so long to lerne.'' - Chaucer`Ars longa, vita 
> brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/

Re: Possible regression in 'wait' command

[Chet Ramey]

On 5/16/21 4:07 PM, Jonas Alfredsson wrote:

Hi Chet,

Thank you for the response.
If I read it correctly you agree that this is a regression from how
it worked previously?


Yes.


I am not a very experienced C programmer, so I am a little bit hesitant
to dive into the code to try to fix it myself. 


No need; I already fixed it. I've attached a patch.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-20210513/builtins/wait.def  2021-04-26 16:50:02.0 -0400
--- builtins/wait.def   2021-05-16 12:43:29.0 -0400
***
*** 181,184 
--- 181,186 
status = 128 + wait_signal_received;
wait_sigint_cleanup ();
+   if (wflags & JWAIT_WAITING)
+   unset_waitlist ();
WAIT_RETURN (status);
  }