Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-user@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 9 Mar 2011 15:36:12 -0800
Message-Id: <201103092336.p29NaCJq010444@pbug.corp.yahoo.com>
From: Greg Roelofs <roelofs@yahoo-inc.com>
Reply-To: Greg Roelofs <roelofs@yahoo-inc.com>
To: common-user@hadoop.apache.org
Subject: Re: java.io.IOException: Task process exit with nonzero status of 134
In-Reply-To: <4D77C783.4090701@uchicago.edu>

Shi Yu wrote:

> An unexpected error has been detected by Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00002b22eecc7b83, pid=13306, tid=1076017504
> #
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-b105 mixed mode)
> # Problematic frame:
> # C  [ld-linux-x86-64.so.2+0x7b83]
> #
> # An error report file with more information is saved as hs_err_pid13306.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp

So it's a 64-bit JVM, and it's invoking a 64-bit ld.so, presumably to load
a native library.  Is your zlib also 64-bit?  I vaguely recall seeing a
SIGFPE a while back, but I don't recall what it turned out to be.  (Seems
unlikely that a 32/64-bit mismatch might cause one, but that's all that
comes to mind offhand.)

Btw, the zlib codec exists in both native (JNI) and Java forms (well, with
the native part buried inside the JDK), so you could also try disabling
native support (set io.native.lib.available to false).  If it still fails,
it's not related to shared libraries.

You could also use the bzip2 codec rather than the default one; bzip2
support exists only in Java form for some inexplicable reason.  (Perhaps
users were blinded by its blazing speed.)

Greg