Bug #304

Gmake's write error

Added by rumcic about 8 years ago. Updated almost 6 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

While compiling wip/jdk14 I came across this write error:
echo Linking vm... ; \
g++ -shared -mimpure-text -static-libgcc -o libjvm_g.so
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
libjsig_g.so /usr/obj/pkgsrc/wip/jdk14/work.rumko/hotspot/src/os/bsd/vm/jsig.c
Making signal interposition lib...
gmake[3]: Leaving directory
`/usr/obj/pkgsrc/wip/jdk14/work.rumko/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake[3]: write error
gmake[2]: *** [the_vm] Error 1
gmake[2]: Leaving directory
`/usr/obj/pkgsrc/wip/jdk14/work.rumko/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake[1]: *** [jvmg] Error 2
gmake[1]: Leaving directory
`/usr/obj/pkgsrc/wip/jdk14/work.rumko/control/build/bsd-i586/hotspot-i586/tmp'
gmake: *** [jvmg] Error 2
*** Error code 2

Stop.
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
non-blocking?

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) :)

History

#1 Updated by corecode about 8 years ago

Is this still present?

If yes, can you provide the full ktrace so that we can find out which part is
setting O_NONBLOCK?

#2 Updated by rumcic about 8 years ago

The ktrace file is at leaf:~rumko/ktrace.out

#3 Updated by corecode almost 6 years ago

i believe we didn't see any write errors for a long time. closing for now.

Also available in: Atom PDF