From nobody@FreeBSD.org  Fri Nov  8 15:57:29 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTP id 90D52E60
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 Nov 2013 15:57:29 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id 7E4BE21E8
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 Nov 2013 15:57:29 +0000 (UTC)
Received: from oldred.freebsd.org ([127.0.1.6])
	by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rA8FvTju096077
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 8 Nov 2013 15:57:29 GMT
	(envelope-from nobody@oldred.freebsd.org)
Received: (from nobody@localhost)
	by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rA8FvTY7096073;
	Fri, 8 Nov 2013 15:57:29 GMT
	(envelope-from nobody)
Message-Id: <201311081557.rA8FvTY7096073@oldred.freebsd.org>
Date: Fri, 8 Nov 2013 15:57:29 GMT
From: "Chad J. Milios" <milios@ccsys.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: audio/liba52 (liba52-0.7.4_2) is not jobs safe
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         183791
>Category:       ports
>Synopsis:       audio/liba52 (liba52-0.7.4_2) is not jobs safe
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-multimedia
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 08 16:00:00 UTC 2013
>Closed-Date:    Mon Dec 30 02:55:46 UTC 2013
>Last-Modified:  Mon Dec 30 02:55:46 UTC 2013
>Originator:     Chad J. Milios
>Release:        9.2-RELEASE
>Organization:
Crop Circle Systems, Inc.
>Environment:
FreeBSD kakashi.ccsys.com 9.2-RELEASE FreeBSD 9.2-RELEASE #1 r256078: Sun Oct  6 07:24:48 UTC 2013     root@shikamaru.ccsys.com:/usr/obj/usr/src/sys/VIMAGE  amd64

>Description:
when it fails it looks something like this:

..
/bin/mkdir -p /usr/ports/audio/liba52/work/stage/usr/local/share/doc/liba52
install  -o root -g wheel -m 444 /usr/ports/audio/liba52/work/a52dec-0.7.4/doc/liba52.txt /usr/ports/audio/liba52/work/stage/usr/local/share/doc/liba52
install  -o root -g wheel -m 444 /usr/ports/audio/liba52/work/a52dec-0.7.4/liba52/a52_internal.h /usr/ports/audio/liba52/work/stage/usr/local/include/a52dec
/usr/bin/strip /usr/ports/audio/liba52/work/stage/usr/local/lib/liba52.so.0
/usr/bin/strip: '/usr/ports/audio/liba52/work/stage/usr/local/lib/liba52.so.0': No such file
*** [post-install] Error code 1

Stop in /usr/ports/audio/liba52.
*** [install] Error code 1

Stop in /usr/ports/audio/liba52.

>How-To-Repeat:
cd /usr/ports/audio/liba52 && sh -c 'for i in `seq 1 20`; do make clean; make stage && log=$log+ || log=$log-; done; echo $log'

>Fix:
make -D DISABLE_MAKE_JOBS install

(of course, that is the user-settable variable and MAKE_JOBS_UNSAFE is the one that should be defined by the port maintainer)


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-multimedia 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Fri Nov 8 16:00:08 UTC 2013 
Responsible-Changed-Why:  
Over to maintainer (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=183791 

From: "Chad J. Milios" <milios@ccsys.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/183791: audio/liba52 (liba52-0.7.4_2) is not jobs safe
Date: Sat, 09 Nov 2013 18:53:29 -0500

 My submitted FIX is WRONG, as is my hypothesis of what the problem is. 
 This is not MAKE_JOBS related as MAKE_JOBS was NOT being used by the 
 port in the first place!
 
 I was erroneously led to that conclusion because coincidentally when i 
 ran 20 iterations while that variable was set, i had 20 successful 
 passes. That was only luck of the draw. I am further investigating the 
 problem but as of yet feel unequipped to offer a real solution. I will 
 follow up again soon with more thorough test results but by all means, 
 someone smarter than i, please feel free to try to dabble on or 
 understand this problem!
 
 After some testing on this box and a different box 50 miles away, i've 
 experienced the following:
 
 * runs of fairly random pass/fail behavior when the boxes are busy with 
 their typical workloads.
 
 * runs tend to develop into patterns when the box is otherwise idle or 
 much less busy. even when otherwise idle, the patterns eventually break 
 (into other patterns) given enough trials
 
 * i've seen as many as 170 consecutive failed iterations
 
 * i've seen as many as 90 consecutive successful iterations
 
 * the longest running pattern i've witnessed was: 14 * (pass, fail, 
 fail, fail, fail) for a total run of over 70 iterations (this on the AMD 
 box)
 
 * my intel box passes well over 75% of the time when otherwise idle, 
 closer to 50/50 when loaded.
 
 * my AMD box passes less than 25% of the time whether idle or loaded.
 
 These boxes are very differently configured and have very different jobs 
 to do. "Otherwise idle" just means "hardly busy", i.e., at 3AM; they 
 were still up and running their respective services. Nothing crashes, 
 nothing dumps, just that error I originally reported in the PR. This 
 should obviously not be considered a scientific test and any relation to 
 system workload is only my less-than-keen observation.
 
 The two boxes both have GPT labeled hard disks, ZFS root, including 
 bootloader. Swap configured to a 512MB zvol reservation, with 0 bytes 
 used. Zero use of UFS according to lsvfs. Both use a fast SATAIII SSD as 
 L2ARC. I use tmpfs. I use procfs. I use fdescfs. Other than that i'd 
 call them pretty typical setups, whatever typical means. Below is a 
 cursory description of each. I can provide more detailed info. I'm going 
 to try to recreate this in a VM as well as try a vanilla+default VM 
 soon, but i can't get around to that for at least a few more days. I 
 hope someone can shed some insight sooner!
 
 1.
 FreeBSD 9.2-RELEASE #1 r256078: Sun Oct  6 07:24:48 UTC 2013
      root@shikamaru.ccsys.com:/usr/obj/usr/src/sys/VIMAGE amd64
 gcc version 4.2.1 20070831 patched [FreeBSD]
 CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3100.09-MHz K8-class CPU)
 Origin = "GenuineIntel"  Id = 0x206a7  Family = 0x6  Model = 0x2a 
 Stepping = 7
 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
 Features2=0x1fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX>
 AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
 AMD Features2=0x1<LAHF>
 TSC: P-state invariant, performance statistics
 real memory  = 34368126976 (32776 MB)
 avail memory = 33130713088 (31595 MB)
 Event timer "LAPIC" quality 600
 ACPI APIC Table: <SUPERM SMCI--MB>
 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 FreeBSD/SMP: 1 package(s) x 4 core(s)
 
 2.
 FreeBSD 9.2-RELEASE #1 r256078: Sun Oct  6 07:24:48 UTC 2013
      root@shikamaru.ccsys.com:/usr/obj/usr/src/sys/VIMAGE amd64
 gcc version 4.2.1 20070831 patched [FreeBSD]
 CPU: AMD FX(tm)-6350 Six-Core Processor              (3900.08-MHz 
 K8-class CPU)
 Origin = "AuthenticAMD"  Id = 0x600f20  Family = 0x15  Model = 0x2 
 Stepping = 0
 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
 Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
 AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
 AMD 
 Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,<b17>,NodeId,TBM,Topology,<b23>,<b24>>
 Standard Extended Features=0x8
 TSC: P-state invariant, performance statistics
 real memory  = 17179869184 (16384 MB)
 avail memory = 16255950848 (15502 MB)
 Event timer "LAPIC" quality 400
 ACPI APIC Table: <7641MS A7641100>
 FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs
 FreeBSD/SMP: 1 package(s) x 6 core(s)
 

From: Peter <pmc@citylink.dinoex.sub.org>
To: bug-followup@FreeBSD.org, milios@ccsys.com
Cc:  
Subject: Re: ports/183791: audio/liba52 (liba52-0.7.4_2) is not jobs safe
Date: Wed, 25 Dec 2013 14:02:13 +0100

 This seems to be a race condition with the timestamps of the Makefiles. 
 "make install" thinks that the Makefiles are outdated, and recreates
 them before doing the install - but now with the target pointing directly 
 to /usr/local and not to the staging area.
 
 In the log we can see this happening: 
 
 >Making install in liba52
 >gmake[1]: Entering directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >cd .. \
 >  && CONFIG_FILES=liba52/Makefile CONFIG_HEADERS= /bin/sh ./config.status
 >config.status: creating liba52/Makefile
 >config.status: executing default-1 commands
 >gmake[1]: Leaving directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >gmake[1]: Entering directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >gmake[2]: Entering directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >/bin/sh ../autotools/mkinstalldirs /usr/local/lib
 
 while on successful runs these lines do not appear:
 
 >Making install in liba52
 >gmake[1]: Entering directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >gmake[2]: Entering directory `/usr/ports/audio/liba52/work/a52dec-0.7.4/liba52'
 >/bin/sh ../autotools/mkinstalldirs /usr/ports/audio/liba52/work/stage/usr/local/lib
 
 
 I could not figure out why or how this happens - but for now a suitable 
 workaround seems to be the following addition to the (main) makefile:
 
 >pre-install:
 >        touch work/a52dec-*/*/Makefile
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Mon Dec 30 02:55:01 UTC 2013 
State-Changed-Why:  
From misfiled PR ports/185282: 

Date: Sun, 29 Dec 2013 21:03:56 -0500 
From: "Chad J. Milios" <milios@ccsys.com> 
To: Peter <pmc@citylink.dinoex.sub.org> 
Subject: Re: [FIXED] ports/183791: audio/liba52 (liba52-0.7.4_2) is not jobs safe 

> On Dec 25, 2013, at 8:02 AM, Peter <pmc@citylink.dinoex.sub.org> wrote: 
> I could not figure out why or how this happens - but for now a suitable= 
> workaround seems to be the following addition to the (main) makefile: 
> 
>Unformatted:
 >> pre-install: 
 >>       touch work/a52dec-*/*/Makefile 
 
 I can confirm that addition to the Makefile worked perfectly for me on all o= 
 f 200 runs on both test servers. Thanks Peter! 
 
 Can someone close the PR after making a commit with the addition of the afor= 
 ementioned pre-install target to /usr/ports/audio/liba52/Makefile please? (N= 
 o revision bump necessary.) 
 
 -Chad= 
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=183791 
