bugmake - Bugs: bug #47995, Parallel double-colon breaks FORCE

 
 

bug #47995: Parallel double-colon breaks FORCE

Submitter:  Joe Crayne <joecrayne>
Submitted:  Tue 24 May 2016 06:04:48 AM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.2 Operating System:  POSIX-Based
Fixed Release:  4.2.1 Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 31 May 2016 07:20:45 AM UTC, comment #1: 

I've fixed this for the next release.  I've tested the fix with various other software although not everything reported to fail.

Paul D. Smith <psmith>
Group administrator
Tue 24 May 2016 06:04:48 AM UTC, original submission:  

This issue was reported on the mailing list as a failure when building git in parallel which uses double-colons to make multiple recipes run.  It was traced to my patch submitted in bug 44742.  Here is a minimal test case:

+verbatum+
all::
        @echo one

all:: joe
        @echo four


joe: FORCE
        touch joe-is-forced

FORCE:

# $ make
# one
# touch joe-is-forced
# four
#
# $ make -j
# one
# four

-verbatum-

Debug messages show that the "joe" target was erroneously pruned by this apparent optimization:

+verbatum+
   /* Prune the dependency graph: if we've already been here on this
     pass through the dependency graph, we don't have to go any further.
     We won't reap_children until we start the next pass, so no state
     change is possible below here until then.  */
  if (f->considered == considered)
    {
      /* Check for the case where a target has been tried and failed but
         the diagnostics haven't been issued. If we need the diagnostics
         then we will have to continue. */
      if (!(f->updated && f->update_status > us_none
            && !f->dontcare && f->no_diag))
        {
          DBF (DB_VERBOSE, _("Pruning file '%s'.\n"));
          return f->command_state == cs_finished ? f->update_status : us_success;
        }
    }
-verbatum-

I believe this is based on an assumption that I've rendered false.  I'm having trouble understanding how it was true in the first place.

An easy fix would be to elide this optimization in the case of parallel double-colon builds.

Paul if you understand the issue better, I'd appreciate your thoughts on it.

Joe Crayne <joecrayne>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37247:  Makefile added by joecrayne (940B - application/octet-stream - Attaching garbled test-case and code paste.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by polyc
  • -email is unavailable- added by joecrayne (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-31 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Component VersionNone 4.2
        Fixed ReleaseNone 4.2.1
        Triage StatusNone Medium Effort
    2016-05-27 polyc Carbon-Copy- Added -email is unavailable-
    2016-05-24 joecrayne Attached File- Added Makefile, #37247

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code