java execution stalls indefinitely
Kúti Zsolt
I am running a gradle script on two apparently identical FreeBSD
installation (7.2 RELEASE, java version "1.6.0_03-p4", up-to-date
installed ports, gradle-0.8).
(gradle comes with its dependencies, beyond that it uses a jdk.)
On one of them it runs fine, on the other it is stalled at
compileGroovy task indefinitely. Nothing happens, no classes are
produced (only the dirs are made).
Using the openjdk6 makes no difference.
I guess, ultimately there must be some difference on the OS level or in
the dependent ports, but have no clue where to find that.
The only trace I could get is by running the script via gradle's
gui, then cancel when stalled. Below see what is outputted (it is
quite possible that it has nothing to do with the case, though).
Any idea appreciated!
Zsolt
%gradle --gui
07:59:12.140 [Thread-17] ERROR o.g.f.ipc.basic.ExternalProcess - Error
copying data java.io.IOException: Bad file descriptor
at java.io.FileInputStream.available(Native Method)
at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.copyData(ExternalProcess.java:219)
at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.run(ExternalProcess.java:198)
at java.lang.Thread.run(Thread.java:619) 07:59:12.140 [Thread-15] ERROR
o.g.f.ipc.basic.ExternalProcess - Error copying data
java.io.IOException: Stream closed at
java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:134)
at java.io.BufferedInputStream.available(BufferedInputStream.java:381)
at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.copyData(ExternalProcess.java:219)
at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.run(ExternalProcess.java:208)
at java.lang.Thread.run(Thread.java:619) 07:59:12.142 [Thread-17] ERROR
o.g.f.ipc.basic.ExternalProcess - Error copying data
java.io.IOException: Bad file descriptor at
java.io.FileInputStream.available(Native Method) at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.copyData(ExternalProcess.java:219)
at
org.gradle.foundation.ipc.basic.ExternalProcess$IOPump.run(ExternalProcess.java:198)
at java.lang.Thread.run(Thread.java:619) 07:59:12.490 [Thread-13] ERROR
o.g.f.ipc.basic.ObjectSocketWrapper - Reading Object
java.io.EOFException at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2748)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280) at
org.gradle.foundation.ipc.basic.ObjectSocketWrapper.readObject(ObjectSocketWrapper.java:54)
at
org.gradle.foundation.ipc.basic.Server.processCommunications(Server.java:245)
at
org.gradle.foundation.ipc.basic.Server.listenForConnections(Server.java:208)
at org.gradle.foundation.ipc.basic.Server.access$000(Server.java:38) at
org.gradle.foundation.ipc.basic.Server$1.run(Server.java:136) at
java.lang.Thread.run(Thread.java:619)
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
Achilleas Mantzios
to see what is the good instance running where the bad instance stalls.
--
Achilleas Mantzios
Kúti Zsolt
Achilleas Mantzios <ach...@matrix.gatewaynet.com> írta:
> You could run both instances in the two machines with ktrace (1) or
> truss(1) to see what is the good instance running where the bad
> instance stalls.
Hello Achilleas,
Thanks for the hint! Running truss shows after some time a repeating
sequence of the following:
...
gettimeofday({1262867164.433795 },0x0)
= 0 (0x0) gettimeofday({1262867164.433851 },0x0) = 0
(0x0) clock_gettime(0,{1262867164.433889494 }) = 0 (0x0)
_umtx_op(0x2820e260,0x8,0x1,0x2820e240,0xbf5e4cec,0x805b528) ERR#60
'Operation timed out'
...
Unfortunately I do not know what this all mean, what setting (if any)
can cause this behaviour.
I searched for _umtx_op on the net and found a similarly behaving python
and OOo case. There was no conclusion, just some suspect of some
threading problem.
I use some serious piece of java programs that work fine.
It is possible that this is a generic OS (ports?) problem and has
nothing to do with Java itself.
Thanks!
Zsolt
Ps.: The only notable difference I can see between the two boxes, that
the problem happens on a Gigabyte mother board with Intel(R) Core(TM)2
Duo CPU E8400, while the other is an Asus with AMD.
Achilleas Mantzios
> Ps.: The only notable difference I can see between the two boxes, that
> the problem happens on a Gigabyte mother board with Intel(R) Core(TM)2
> Duo CPU E8400, while the other is an Asus with AMD.
Have you tried swapping disks? put the disks of intel to amd and vice versa?
> _______________________________________________
> freebs...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-java
> To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
>
--
Achilleas Mantzios
Zsolt Kúti
Achilleas Mantzios <ach...@matrix.gatewaynet.com> wrote:
> >
> > Ps.: The only notable difference I can see between the two boxes,
> > that the problem happens on a Gigabyte mother board with Intel(R)
> > Core(TM)2 Duo CPU E8400, while the other is an Asus with AMD.
>
> Have you tried swapping disks? put the disks of intel to amd and vice
> versa?
Unfortunately the problem is at work and that disc is not really
allowed to be moved, the other is at home, but I will check if it is
doable.
Perhaps I should check every dependency of jdk for threading options?
Python is already rebuilt, just as jdk16, with no effect. There is a
libpthread-stubs-0.3_3 dependency, but that port itself has no
configurable option.
Thanks!
Zsolt
------------
Zsolt Kúti