Project

General

Profile

Actions

Bug #304

closed

Gmake's write error

Added by rumcic over 17 years ago. Updated about 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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...
gmake3: Leaving directory
`/usr/obj/pkgsrc/wip/jdk14/work.rumko/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake3: write error
gmake2: * [the_vm] Error 1
gmake2: Leaving directory
`/usr/obj/pkgsrc/wip/jdk14/work.rumko/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake1:
[jvmg] Error 2
gmake1: 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) :)

Actions #1

Updated by corecode about 18 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?

Actions #2

Updated by rumcic about 18 years ago

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

Actions #3

Updated by corecode about 18 years ago

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

Actions

Also available in: Atom PDF