[HADOOP-15859] ZStandardDecompressor.c mistakes a class for an instance

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 2.9.0, 3.0.0-alpha2
• Fix Version/s: 2.10.0, 3.2.0, 2.9.2, 3.0.4, 3.1.2
• Target Version/s: 2.10.0, 3.2.0, 2.9.2, 3.0.4, 3.1.2
• Hadoop Flags: Reviewed
• Assignee: Jason Darrell Lowe Assign to me
• Reporter: Ben Lau
• Created: 16/Oct/18 18:31
• Updated: 07/Nov/18 01:34
• Resolved: 17/Oct/18 19:48

Description

As a follow up to HADOOP-15820, I was doing more testing on ZSTD compression and still encountered segfaults in the JVM in HBase after that fix. 

I took a deeper look and realized there is still another bug, which looks like it's that we are actually calling setInt() on the "remaining" variable on the ZStandardDecompressor class itself (instead of an instance of that class) because the Java stub for the native C init() function is marked static, leading to memory corruption and a crash during GC later.

Initially I thought we would fix this by changing the Java init() method to be non-static, but it looks like the "remaining" setInt() call is actually unnecessary anyway, because in ZStandardDecompressor.java's reset() we set "remaining" to 0 right after calling the JNI init() call. So ZStandardDecompressor.java init() doesn't have to be changed to an instance method, we can leave it as static, but remove the JNI init() call's "remaining" setInt() call altogether.

Furthermore we should probably clean up the class/instance distinction in the C file because that's what led to this confusion. There are some other methods where the distinction is incorrect or ambiguous, we should fix them to prevent this from happening again.

I talked to Jason Darrell Lowe who further pointed out the ZStandardCompressor also has similar problems and needs to be fixed too.

Issue Links

• is caused by: HADOOP-13578 Add Codec for ZStandard Compression
• relates to: HADOOP-15820 ZStandardDecompressor native code sets an integer field as a long