[HADOOP-8756] Fix SEGV when libsnappy is in java.library.path but not LD_LIBRARY_PATH

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0.2-alpha
• Fix Version/s: 2.0.3-alpha
• Component/s: native
• Hadoop Flags: Reviewed
• Assignee: Colin McCabe
• Reporter: Colin McCabe
• Created: 01/Sep/12 01:01
• Updated: 15/Feb/13 13:12
• Resolved: 03/Oct/12 00:11

Description

We use System.loadLibrary("snappy") from the Java side. However in libhadoop, we use dlopen to open libsnappy.so dynamically. System.loadLibrary uses java.library.path to resolve libraries, and dlopen uses LD_LIBRARY_PATH and the system paths to resolve libraries. Because of this, the two library loading functions can be at odds.

We should fix this so we only load the library once, preferably using the standard Java java.library.path.

We should also log the search path(s) we use for libsnappy.so when loading fails, so that it's easier to diagnose configuration issues.

Issue Links

• breaks: HADOOP-9309 test failures on Windows due to UnsatisfiedLinkError in NativeCodeLoader#buildSupportsSnappy
• is related to: HADOOP-8806 libhadoop.so: dlopen should be better at locating libsnappy.so, etc.
• is related to: HBASE-7080 TestHFileOutputFormat.testColumnFamilyCompression failing due to UnsatisfiedLinkError