Abel Morelos Abel Morelos - 1 month ago 25
Java Question

MapReduce job fails with ExitCodeException exitCode=255

I am trying to run a MapReduce job that requires a shared library (a .so file). If I use the shared library from an standalone Java program I don't have problems at all (this program used java.library.path to find the library), but if I try to use the same native methods from the MapReduce program then I obtain the exception I pasted below (for the MapReduce program I am using the Distributed cache).

I know the native library is actually being loaded and the native code (C++) is called from MapReduce since the native function prints something to the standard output but after the native function returns I see a "Signal caught, exiting" message and then the application logs only provide the information below (I think the 255 is a -1 in this case) but that's it, I don't know where else to look for information to debug this issue or to figure out out why there is an uncaught signal. Any pointers about where to look for debugging/log info are appreciated.

Exception from container-launch: ExitCodeException exitCode=255:
ExitCodeException exitCode=255: at
org.apache.hadoop.util.Shell.runCommand(Shell.java:538) at
org.apache.hadoop.util.Shell.run(Shell.java:455) at
at java.util.concurrent.FutureTask.run(FutureTask.java:262) at
at java.lang.Thread.run(Thread.java:745)

Container exited with a non-zero exit code 255


I already solved my own problem, but I am not sure about how to explain this. In C++ I have a method that returns to Java a pointer as a jlong (I was casting the pointer to jlong) and everything worked OK when the library was called from a standalone application, but the same code failed when called from Yarn.

I wrote a custom signal handler and that helped me know that it was a segment fault error, so I was doing something wrong with the pointers or the memory. When trying to call the same library from MapReduce (Yarn) is when I was having the previous exception. I changed the cast for the pointer to long instead of jlong and that is what I returned to Java. Later, when the handle to the native object was invoked the problem was not happening again. I am not sure why this helped, but something is going on with how Yarn manipulates the environment.

Best regards.