ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: Jikes dramas
Date Mon, 20 Aug 2001 23:07:40 GMT
Peter Donald wrote:

> > The confusing part here is that when jikes complied for glibc-2.2 is
> > used, standalone compilations are fine. But when called from Ant, it
> > dumps the core. So, there must be something different in the way jikes
> > is called from Ant then from the shell... And yet, the version compiled
> > for glibc-2.1 works fine. This could be one of those infamous
> > RedHat-7.0-we-used-a-bad-compiler-to-create-it things, who knows...
> 
> This is a random guess that may be completely wrong but ...  it is possibly
> that your "java" executable is actually a shell script that sets thing like
> LD_LIBRARY_* (or whatever the environment variables are). These are inherited
> by any sub processes including your executable. This causes problems when
> these variables cause your programs to fail. My only solution is to get a
> statically linked executable, one that works with the JVM or write a wrapper
> script that unsets the environment variables.

We have the offender: libpreemptive_close.so

This library is a workaround for bug #4344135 of JDK 1.3.1 on Linux:

--------------------------------------------
# A thread currently waiting on a I/O operation will not wake up if one
# of the files involved is actually closed (last close - the file is
# no longer accessible but the thread is still waiting in the kernel).
# The library libpreemptive_close.so is dynamically linked to the JVM
# iff the J2SE_PREEMPTCLOSE environment variable is set to 1
#
if [ "$J2SE_PREEMPTCLOSE" = 1 ]; then
   LD_PRELOAD=${LD_PRELOAD}:libpreemptive_close.so
   export LD_PRELOAD
fi
--------------------------------------------

Unsetting the J2SE_PREEMPTCLOSE gets rid of the problem.

Thanks for your help.

Bojan

Mime
View raw message