bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #38420] $(realpath ...) doesn't recover from signals


From: Brian Vandenberg
Subject: [bug #38420] $(realpath ...) doesn't recover from signals
Date: Tue, 26 Feb 2013 22:21:45 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)

URL:
  <http://savannah.gnu.org/bugs/?38420>

                 Summary: $(realpath ...) doesn't recover from signals
                 Project: make
            Submitted by: phantal
            Submitted on: Tue 26 Feb 2013 10:21:44 PM GMT
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: None
        Operating System: None
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

func_realpath doesn't check errno at all.  When running in parallel builds, if
the parent gmake process receives a signal in the middle of calling `realpath`
it'll act as though the file does not exist.

Suggested fix:


2028c2017
<  while ( errno == EINTR || (path = find_next_token (&p, &len)) != 0)
---
>  while ( (path = find_next_token (&p, &len)) != 0)


The above use of || will shortcut and prevent it from pre-maturely grabbing
the next token.

I haven't evaluated this to see if something more comprehensive could/should
be done (eg, checking other "errno" values, etc).

I haven't finished validating whether this completely resolves the problem,
but so far it seems to have done just that.  Furthermore, I don't have any
ideas for how to implement a test for this as it's a race condition that isn't
necessarily easy to reproduce.

I highly recommend evaluating other system functions used by gmake to
determine whether this sort of issue could crop up elsewhere (eg, `$(abspath
...)`, etc)




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38420>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]