893875 - makefiles: .BindingGen deps in dom/bindings - race condition

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Joey Armstrong [:joey]]

dom/bindings/Makefile.in

Header and cpp targets can independently trigger the .BindingGen target:
  $(binding_header_files): .BindingGen
  $(binding_cpp_files): .BindingGen

.BindingGen regenerates .all-webidl-file-list and .changed-dependency-list lists.
If both deps process this target they may stomp on each-other's data file.  May succeed if files are regenerated before pythonpath is called.  Bad input conditions will be an empty file, partially regenerated file or .all has been regenerated but .changed has not.

Comment 1

[Joey Armstrong [:joey]]

Also overhead from one shell can be removed by replacing $(MKDIR) -p .deps with $(call mkdir_deps,.deps).

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'm not sure I follow.

If we have two targets that both depend on the same thing, then I would expect that thing to be brought up to date atomically from the point of view of make, no?  Otherwise how can Makefiles possibly work?

Comment 3

[Joey Armstrong [:joey]]

(In reply to Boris Zbarsky (:bz) from comment #2)
> I'm not sure I follow.
> 
> If we have two targets that both depend on the same thing, then I would
> expect that thing to be brought up to date atomically from the point of view
> of make, no?  Otherwise how can Makefiles possibly work?

The problem is header and cpp deps will be checked independently/asynchronously by make, they are each assigned 'a slot'.

The .BindingGen target will be considered stale until $(TOUCH) $@ at the bottom is run.

Enter headers: stale deps are detected.  Begin re-generating files, call pythonpath then touch to update .BindingGen.

If while .BindingGen is processed for headers, but before touch at the bottom is reached, cpp performs the dependency check.

cpp will also detect .BindingGen as stale and will begin running the same sets of commands to update the target.


This will be a small window but if one attempts to run pythonpath while the other is regenerating .all* or .changed* the race condition will bite.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I was under the impression that make built the dependency graph, then processed it starting at the roots.  Is that not so?

Comment 5

[Boris Zbarsky [:bzbarsky]]

As in, if it works like you describe then _anything_ that has multiple targets depending on it would be buggy, afaict.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

From the manual: "Be aware that a given prerequisite will only be built once per invocation of make, at most."