Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"env process" dumps two coredumps instead of one when killed #6760

Open
Ecordonnier opened this issue Oct 1, 2024 · 1 comment
Open

"env process" dumps two coredumps instead of one when killed #6760

Ecordonnier opened this issue Oct 1, 2024 · 1 comment
Labels

Comments

@Ecordonnier
Copy link
Contributor

This used to work correctly with 0.0.16, but it stopped working after #4011 was merged (shortly after the 0.0.16 release):

Killing a process started using env should cause one coredump, not two:
With version 0.0.27 "env" generates its own coredump:

ecordonnier@lj8k2dq3:~/dev/coreutils$ ./target/release/coreutils env --version
uu_env 0.0.27
ecordonnier@lj8k2dq3:~/dev/coreutils$ ./target/release/coreutils env sleep 100 &
[1] 3724248
ecordonnier@lj8k2dq3:~/dev/coreutils$ pidof coreutils
3724248
ecordonnier@lj8k2dq3:~/dev/coreutils$ pidof sleep
3724252
ecordonnier@lj8k2dq3:~/dev/coreutils$ kill -11 $(pidof sleep)
ecordonnier@lj8k2dq3:~/dev/coreutils$ 
[1]+  Segmentation fault      (core dumped) ./target/release/coreutils env sleep 100
ecordonnier@lj8k2dq3:~/dev/coreutils$ 

/# coredumpctl list
TIME                         PID UID GID SIG     COREFILE EXE                 SIZE
Tue 2024-10-01 13:58:07 CEST 3724252 23274 23274 SIGSEGV present  /usr/bin/sleep                                                                           24.5K
Tue 2024-10-01 13:58:07 CEST 3724248 23274 23274 SIGSEGV present  /home/ecordonnier/dev/coreutils/target/release/coreutils                                 95.1K

See behavior of GNU coreutils where only one coredump is generated in this case:

ecordonnier@lj8k2dq3:~$ env --version
env (GNU coreutils) 9.4
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Mlynarik, David MacKenzie, and Assaf Gordon.
ecordonnier@lj8k2dq3:~$ env sleep 100 &
[1] 3676807
ecordonnier@lj8k2dq3:~$ pidof sleep
3676807
ecordonnier@lj8k2dq3:~$ pidof env
ecordonnier@lj8k2dq3:~$ kill -11 $(pidof sleep)
ecordonnier@lj8k2dq3:~$ 
[1]+  Segmentation fault      (core dumped) env sleep 100
    
ecordonnier@lj8k2dq3:~$ coredumpctl list
Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
TIME                             PID   UID   GID SIG     COREFILE EXE                                                                                       SIZE
Tue 2024-10-01 13:50:43 CEST 3676807 23274 23274 SIGSEGV present  /usr/bin/sleep                                                                           24.4K

@samueltardieu
Copy link
Contributor

This is probably due to the non-use of exec*() functions, as describe in the env.rs file:

        /*
         * On Unix-like systems Command::status either ends up calling either fork or posix_spawnp
         * (which ends up calling clone). Keep using the current process would be ideal, but the
         * standard library contains many checks and fail-safes to ensure the process ends up being
         * created. This is much simpler than dealing with the hassles of calling execvp directly.
         */

GNU coreutils reuses the same process by calling exec*() as your pidof env empty output shows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants