Gmake's write error

Rumko rumcic at
Wed Aug 30 23:19:23 PDT 2006

While compiling wip/jdk14 I came across this write error:
echo Linking vm... ; \
        g++ -shared -mimpure-text -static-libgcc  -o 
functionAtStart.o accessFlags.o ad_i486.o ad_i486_clone.o ad_i486_expand.o 
ad_i486_format.o ad_i486_gen.o ad_i486_misc.o ad_i486_peephole.o 
ad_i486_pipeline.o adapters.o adapters_i486.o adaptiveSizePolicy.o addnode.o 
ageTable.o allocation.o aprofiler.o arguments.o array.o arrayKlass.o 
arrayKlassKlass.o arrayOop.o assembler.o assembler_bsd_i486.o 
assembler_i486.o atomic.o binaryTreeDictionary.o bitMap.o block.o 
blockOffsetTable.o buildOopMap.o bytecode.o bytecodeHistogram.o 
bytecodeInfo.o bytecodeStream.o bytecodeTracer.o bytecodes.o bytecodes_i486.o 
c2_globals.o c2_init_i486.o c2compiler.o cInterpreter.o cSpaceCounters.o 
callGenerator.o callnode.o carRememberedSet.o cardTableExtension.o 
cardTableModRefBS.o cardTableRS.o cartable.o cfgnode.o cha.o chaitin.o 
chaitin_bsd.o ciArray.o ciArrayKlass.o ciConstant.o ciConstantPoolCache.o 
ciEnv.o ciExceptionHandler.o ciField.o ciFieldLayout.o ciFlags.o ciInstance.o 
ciInstanceKlass.o ciInstanceKlassKlass.o ciKlass.o ciKlassKlass.o ciMethod.o 
ciMethodData.o ciMethodKlass.o ciNullObject.o ciObjArrayKlass.o 
ciObjArrayKlassKlass.o ciObject.o ciObjectFactory.o ciOopMap.o ciScope.o 
ciSignature.o ciStreams.o ciSymbol.o ciSymbolKlass.o ciType.o 
ciTypeArrayKlass.o ciTypeArrayKlassKlass.o ciTypeFlow.o ciUtilities.o 
cLinking vm...
Linking launcher...
echo Making signal interposition lib...; \
        gcc -g -D_GNU_SOURCE -D_REENTRANT -static-libgcc -shared -fPIC -o /usr/obj/pkgsrc/wip/jdk14/work.rumko/hotspot/src/os/bsd/vm/jsig.c
Making signal interposition lib...
gmake[3]: Leaving directory 
gmake[3]: write error
gmake[2]: *** [the_vm] Error 1
gmake[2]: Leaving directory 
gmake[1]: *** [jvmg] Error 2
gmake[1]: Leaving directory 
gmake: *** [jvmg] Error 2
*** Error code 2

bmake: stopped in /usr/pkgsrc/wip/jdk14
*** Error code 1

It is repeatable. Matt was debugging it, but if there are people with more 
time out there it would be even better.

I did have a ktrace.out available (which I have to find and upload it to leaf) 
and Matt did download it:
>  I downloaded the ktrace.  As far as I can tell it failed running
>     a 'cat'.
>  69086 cat      RET   write 1286/0x506
>  69086 cat      CALL  write(0x1,0x28060506,0xc22)
>  69086 cat      RET   write -1 errno 35 Resource temporarily unavailable
>  69086 cat      CALL  write(0x2,0xbfbfd830,0x5)
>  69086 cat      RET   write -1 errno 35 Resource temporarily unavailable
>  69086 cat      CALL  write(0x2,0x805dcc8,0x2)
>  69086 cat      GIO   fd 2 wrote 2 bytes
>        ": "
>  69086 cat      RET   write 2
>  69086 cat      CALL  exit(0x1)
>  69085 sh       RET   wait4 69086/0x10dde
>  69085 sh       CALL  exit(0x1)
>     The error is a temporary resource error which means that stdout and
>     stderr were set to non-blocking I/O.  It used to be that the threads
>     library set non-blocking I/O on stdout and stderr, and that is what we
>     fixed.  I don't know what is going on here.
>     Please run this program from the same shell that you ran the bmake
>     from, this will tell me if stdout was set to non-blocking before
>     bmake was run.
> include <stdio.h>
> #include <fcntl.h>
> int
> main(int ac, char **av)
> {
>     printf("DESC FLAGS %04x\n", fcntl(1, F_GETFL, 0));
>     return(0);
> }

The program outputted "DESC FLAGS 0002" which according to Matt should 
output ... but why then during the build the descriptors were set to 

I also bugged Joerg on IRC about the write error and he (if I understood him 
correctly) suggested that another library that uses select(2) calls could 
have set them to non-blocking.

Now ... how to figure out which one? If I ktraced an app that I linked with 
another library, if that library does set the descriptors to non-blocking, 
can I see that in ktrace and how? And the most important question ... do I 
have to use all the functions the library provides or do I just manually link 
the app to the library, ktrace the newly linked app and I can see if that 
library is at fault or not? If it's as easy as that I can just try randomly 
linking libraries and ktrace the app (a "Hello world" app) :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: PGP signature"
URL: <>

More information about the Bugs mailing list