mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: "Zhang, Huilin (Rebecca) (CN)" <Rebecca.Zhang.CN@windriver.com>
Cc: Markus Wichmann <nullplan@gmx.net>,
	"musl@lists.openwall.com" <musl@lists.openwall.com>,
	"Deng, Wenbin (CN)" <Wenbin.Deng.CN@windriver.com>
Subject: Re: [PATCH] __libc_exit_fini forgets to do pthread_mutex_unlock
Date: Wed, 2 Jul 2025 10:18:53 -0400	[thread overview]
Message-ID: <20250702141853.GH1827@brightrain.aerifal.cx> (raw)
In-Reply-To: <LV3PR11MB874336519A7449974C323475DD40A@LV3PR11MB8743.namprd11.prod.outlook.com>

On Wed, Jul 02, 2025 at 06:06:11AM +0000, Zhang, Huilin (Rebecca) (CN) wrote:
> Hello, Markus,
> 
> Please see attached test code main.c. Assume we compile it with MUSL and generate the executable program named myApp.
> This myApp needs an input parameter which is an another executable program. If this parameter pointed to a nonexistent
> program, this myApp will get stuck.
> 
> For example: (aaa is a nonexistent program)
> ./myApp aaa
> 
> 
> The attached .png file is the snapshot that I ran myApp on ubutntu 22.04.3.
> 
> Thanks,
> Rebecca
> 
> 
> -----Original Message-----
> From: Markus Wichmann <nullplan@gmx.net> 
> Sent: Wednesday, July 2, 2025 12:31 PM
> To: musl@lists.openwall.com
> Cc: Zhang, Huilin (Rebecca) (CN) <Rebecca.Zhang.CN@windriver.com>; Deng, Wenbin (CN) <Wenbin.Deng.CN@windriver.com>
> Subject: Re: [musl] [PATCH] __libc_exit_fini forgets to do pthread_mutex_unlock
> 
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> Am Wed, Jul 02, 2025 at 10:28:54AM +0800 schrieb rebecca.zhang.cn@windriver.com:
> > From: Rebecca Zhang <rebecca.zhang.cn@windriver.com>
> >
> > This commit fixes the issue that __libc_exit_fini only do 
> > pthread_mutex_lock, but forget to do pthread_mutex_unlock.
> > ---
> >  ldso/dynlink.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/ldso/dynlink.c b/ldso/dynlink.c index ceca3c9..7885675 
> > 100644
> > --- a/ldso/dynlink.c
> > +++ b/ldso/dynlink.c
> > @@ -1492,6 +1492,7 @@ void __libc_exit_fini()
> >                       fpaddr(p, dyn[DT_FINI])();  #endif
> >       }
> > +     pthread_mutex_unlock(&init_fini_lock);
> >  }
> >
> >  void __ldso_atfork(int who)
> > --
> > 2.34.1
> >
> I think that is a deliberate omision. __libc_exit_fini() is called
> on process exit. After it runs, it must not run again, and no new
> initializer must run at all. The process will exit very soon anyway.
> The only way to deadlock here is if a destructor calls exit(), which
> they aren't allowed to do.
> 
> Ciao,
> Markus

> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <unistd.h>
> 
> void main(int argc, char *argv[]) {
>   if (argc < 2) {
>     fprintf(stderr, "usage: %s <program> [args...]\n", argv[0]);
>     exit(EXIT_FAILURE);
>   }
> 
>   printf("parent process PID=%d is starting\n", getpid());
> 
>   pid_t pid = vfork(); // use vfork to create child process
> 
>   if (pid < 0) {
>     // vfork fail
>     perror("vfork fail");
>     exit(EXIT_FAILURE);
>   } else if (pid == 0) {
>     // child process
>     printf("child process PID=%d will start: %s\n", getpid(), argv[1]);
> 
>     // execute program which is pass in via argv
>     execvp(argv[1], &argv[1]);
> 
>     perror("execvp fail");
>     exit(EXIT_FAILURE);
>   } else {
>     // parent process
>     printf("parent process PID=%d wait for child process PID=%d\n", getpid(), pid);
> 
>     int status;
>     pid_t wait_pid = waitpid(pid, &status, 0); // wait for child process terminating
> 
>     if (wait_pid < 0) {
>       perror("waitpid fail");
>     } else if (WIFEXITED(status)) {
>       printf("child process exit???exit code: %d\n", WEXITSTATUS(status));
>     } else if (WIFSIGNALED(status)) {
>       printf("child process is terminated by signal???signal is: %d\n", WTERMSIG(status));
>     }
> 
>     printf("parent process exit\n");
>   }
> 
>   exit(0);
> }

This is completely expected. You cannot call exit in the child after
vfork. The only permissible actions are execve (and variants) and
_exit.

Rich


  parent reply	other threads:[~2025-07-02 14:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02  2:28 [PATCH] __libc_exit_fini forgets to do pthread_mutex_unlock rebecca.zhang.cn
2025-07-02  4:30 ` Markus Wichmann
2025-07-02  6:06   ` [musl] " Zhang, Huilin (Rebecca) (CN)
2025-07-02  6:20     ` Deng, Wenbin (CN)
2025-07-02 14:18     ` Rich Felker [this message]
2025-07-02 14:33   ` Rich Felker
2025-07-03  1:44     ` Zhang, Huilin (Rebecca) (CN)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250702141853.GH1827@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=Rebecca.Zhang.CN@windriver.com \
    --cc=Wenbin.Deng.CN@windriver.com \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).