462740 - Building Spidermonkey (js/src) with -j3 fails

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

$ make -C js/src clean
$ make -C js/src -j3
...
link -NOLOGO -DLL -OUT:js3250.dll -PDB:js3250.pdb -SUBSYSTEM:WINDOWS  jsapi.obj
jsarena.obj jsarray.obj jsatom.obj jsbool.obj jscntxt.obj jsdate.obj jsdbgapi.ob
j jsdhash.obj jsdtoa.obj jsemit.obj jsexn.obj jsfun.obj jsgc.obj jshash.obj jsin
terp.obj jsinvoke.obj jsiter.obj jslock.obj jslog2.obj jslong.obj jsmath.obj jsn
um.obj jsobj.obj json.obj jsopcode.obj jsparse.obj jsprf.obj jsregexp.obj jsscan
.obj jsscope.obj jsscript.obj jsstr.obj jsutil.obj jsxdrapi.obj jsxml.obj prmjti
me.obj jstracer.obj Assembler.obj Fragmento.obj LIR.obj RegAlloc.obj avmplus.obj
 Nativei386.obj jsbuiltins.obj    js3240.res -MANIFESTUAC:NO -NXCOMPAT -SAFESEH
-DYNAMICBASE  -DEBUG -DEBUGTYPE:CV        c:/moz/builds/hg-dbg/dist/lib/nspr4.li
b c:/moz/builds/hg-dbg/dist/lib/plc4.lib c:/moz/builds/hg-dbg/dist/lib/plds4.lib
  kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib
link -NOLOGO -OUT:js.exe -PDB:js3250.pdb  -MANIFESTUAC:NO -NXCOMPAT -SAFESEH -DY
NAMICBASE  -DEBUG -DEBUGTYPE:CV        js.obj jsapi.obj jsarena.obj jsarray.obj
jsatom.obj jsbool.obj jscntxt.obj jsdate.obj jsdbgapi.obj jsdhash.obj jsdtoa.obj
 jsemit.obj jsexn.obj jsfun.obj jsgc.obj jshash.obj jsinterp.obj jsinvoke.obj js
iter.obj jslock.obj jslog2.obj jslong.obj jsmath.obj jsnum.obj jsobj.obj json.ob
j jsopcode.obj jsparse.obj jsprf.obj jsregexp.obj jsscan.obj jsscope.obj jsscrip
t.obj jsstr.obj jsutil.obj jsxdrapi.obj jsxml.obj prmjtime.obj jstracer.obj Asse
mbler.obj Fragmento.obj LIR.obj RegAlloc.obj avmplus.obj Nativei386.obj jsbuilti
ns.obj js3240.res c:/moz/builds/hg-dbg/dist/lib/nspr4.lib c:/moz/builds/hg-dbg/d
ist/lib/plc4.lib c:/moz/builds/hg-dbg/dist/lib/plds4.lib   kernel32.lib user32.l
ib gdi32.lib winmm.lib wsock32.lib advapi32.lib
   Bibliothek "js3250.lib" und Objekt    Bibliothek "js.lib" und Objekt "j"js32s
.exp"50 werden erstellt.
.exp" werden erstellt.
LINK : fatal error LNK1318: Unexpected PDB error: ACCESS_DENIED (15) "c:\moz\builds\hg-dbg\js\src\js3250.pdb".

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

(this is with VC9 express on windows vista)

Comment 2

[Rain [:rain1] (inactive)]

Yeah, I had the same thing (VC9 on Vista). Happened the first time (clean build with -j3) but went fine the next, still with -j3.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same here with the identical configuration. It worked fine on a second try yesterday. But now it stopped again after a hg pull and hg update.

Comment 4

[Benjamin Smedberg]

Attachment: Use a separate PDB for compiled files and for the final library/program, rev. 1

This patch uses a single (constant-named, even) PDB file for all compiled files, and a separate PDB file is generated by the linker for the final DLL or program.

Comment 5

[(not currently active) Ted Mielczarek]

Comment on attachment 346326 [details] [diff] [review]
Use a separate PDB for compiled files and for the final library/program, rev. 1

 # make builds on Windows.  Now we just write to a pdb file per compiled file.
 # See bug 286179 <https://bugzilla.mozilla.org/show_bug.cgi?id=286179> for
 # details. -- [e-mail]

Can you kill this outdated and no-longer-correct comment?

Otherwise looks fine. Do you want to make the same COMPILE/LINK distinction for HOST_PDBFILE?

Comment 6

[Benjamin Smedberg]

Pushed http://hg.mozilla.org/mozilla-central/rev/5d832205b7fb

The distinction mainly exists for performance reasons, and since host-compiles are uncommon we can just leave them in the slow path (separate PDB for each object file).