Open gharris1727 opened 1 year ago
As it's tagged "Java" I've had a look at this, but not got far. I wasn't able to repro on an M1 Max running Ventura 13.1.
Looking at the stack trace, it appears to me that it is crashing while dumping the SST file, while running compaction ? But I can't see where the dump is initiated and I wonder if it is either (a) being run manually (by the Kafka scripts ?) or (b) part of a crash dump hook.
Whatever the core issue, it is a RocksDB core failure I think, rather than the Java API passing something wrong in. @akankshamahajan15 could you or someone else on the core team with knowledge of compaction see if you can make more sense of it ?
I had a similar issue on a project (not exactly the same trace though).
The SIGSEGV in case was due to the column family handle. To avoid it, I had to "force" the loading of the descriptor to be sure it's populate:
ColumnFamilyHandle handle = ...;
handle.getDescriptor();
I hope it helps.
A project that I'm working on (Kafka Streams) uses RocksDB via JNI. While running tests, I encountered a SIGSEGV. Downstream issue: https://issues.apache.org/jira/browse/KAFKA-14555
Expected behavior
No SIGSEGV
Actual behavior
JVM Crash with the following stacktrace:
Full log: hs_err_pid88913.log
Steps to reproduce the behavior
trunk
./gradlew streams:cleanTest streams:test
Note: I have only seen this failure once so far and have not yet verified these reproduction steps. I am using macOS Monterey 12.6 with an arm64/aarch64 Apple Silicon M1 Max.