race condition due to install-file macro ?

[Kelly Ohair]

solaris 10u6 systems require all the latest patches
there is some kind of zip issue on the systems that was fixed in a patch to 10u6

RE or Katleman should know what systems were patched

Heikki ran into this many months ago too 

can not dig up details now


Sent from my iPhone

On Jan 3, 2013, at 2:44, David Holmes <david.holmes at oracle.com> wrote:

> Thanks Erik.
> 
> Well the jar files exist AFAICS.
> 
> I should mention that there is sometimes a similar failure in the Hudson builds where the rt.jar recipe give a Zip error opening rt.jar for update when the previous line of the recipe created rt.jar.
> 
> I can not explain either of the failures. They certainly seem like timing issues though.
> 
> David
> -----
> 
> On 3/01/2013 6:11 PM, Erik Joelsson wrote:
>> Hello,
>> 
>> Short answer is no, there has to be some other explanation, like a jar
>> file actually is corrupt or it is missing from the dependency list
>> $(JRE_LIB_TARGETS). The latter is the most probable cause I think. These
>> errors can sometimes be very subtle and hard to find. If this could
>> happen, make wouldn't be a very useful tool imho.
>> 
>> Longer version. The way make is said to work, barring bugs of course,
>> the following happens. First the makefile is parsed, reading all the
>> rules and setting up the dependency tree. For each rule, it is
>> determined if the target needs to be built or not and what other targets
>> need to be built before it. When all that is done, the execution phase
>> begins. When execution begins, the targets and order is decided and will
>> not change. (Except of course for parallel execution where targets not
>> dependent on each other can execute in any order.) A target will not
>> start executing before all it's dependents are done, and done means the
>> full recipe having executed and succeeded, not just the file showing up.
>> 
>> /Erik
>> 
>> On 2013-01-03 08:05, David Holmes wrote:
>>> Given:
>>> 
>>> $(JRE_IMAGE_DIR)/lib/meta-index: $(JRE_LIB_TARGETS)
>>> $(ECHO) $(LOG_INFO) Generating $(patsubst $(OUTPUT_ROOT)/%,%,$@)
>>> $(CD) $(@D)&& $(TOOL_BUILDMETAINDEX) -o meta-index `$(LS) *.jar |
>>> $(SED) 's/JObjC\.jar//g'`
>>> 
>>> where the JRE_LIB_TARGETS all involve copying a file from the build
>>> output directory to the correct images directory ... a given jar file
>>> will appear in the images directory once the copy commences. Can it be
>>> that make will see the existence of that file as indicating a
>>> satisfactory meeting of the prerequisite and commence the recipe for
>>> creating the meta-index thus allowing the indexing tool to start
>>> working on a jar file that is still in the process of being copied?
>>> 
>>> I don't know in detail how the parallel aspects of make really work.
>>> 
>>> It may be that the install-file macro needs to copy to a tmp name and
>>> then rename to the final name once the cp is complete.
>>> 
>>> I haven't encountered this myself but others experimenting with the
>>> Profiles builds have run into an error from the indexing tool
>>> indicating a jar file could not be opened/read - which is explainable
>>> if the file was still being copied.
>>> 
>>> Thoughts?
>>> 
>>> David