[
https://issues.apache.org/jira/browse/MINIFICPP-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16826053#comment-16826053
]
Daniel Bakai edited comment on MINIFICPP-824 at 4/25/19 1:15 PM:
-----------------------------------------------------------------
extensions/rockdb-repos uses rocksdb. It either sets the include paths provided
by find_package or sets the include path directly to the rocksdb include dir in
thirdparty, based on whether we want to build rocksdb and whether find_package
has found a system rocksdb. It's the same with linking: we link with either the
lib found with find_package or directly the module built by us.
Viewing the compilation of extensions/rockdb-repos with VERBOSE=1 shows that it
actually uses the proper include dirs.
The problem is with libminifi/test/rocksdb-tests/RepoTests.cpp. It includes
extensions/rockdb-repos/FlowFileRecord.h, which in turn includes the rocksdb
headers and FlowFileRecord's destructor is defined in it, and calls
rocksd::DB's destructor.
That means that the destructor is interpreted and compiled under
libminifi/test/rocksdb-tests/, for which the first include is
/usr/local/include, where it finds the system rocksdb headers, causing the
aforementioned destructor problem.
libminifi/test/rocksdb-tests's CMakeList actually sets
${ROCKSDB_THIRDPARTY_ROOT}/include as a target include directory even if we
don't build rocksdb (which may be problematic if we actually wanted to use
system rocksdb), but it is useless, as /usr/local/include will have precedence.
Even if we completely remove the option to use system rocksdb, any time
/usr/local/include is included before our thirdparty include dir, the same
issue will happen.
I'm not sure what is the best solution for this problem. [~phrocker]?
was (Author: bakaid):
extensions/rockdb-repos uses rocksdb. It either sets the include paths provided
by find_package or sets the include path directly to the rocksdb include dir in
thirdparty, based on whether we want to build rocksdb and whether find_package
has found a system rocksdb. It's the same with linking: we link with either the
lib found with find_package or directly the module built by us.
Viewing the compilation of extensions/rockdb-repos with VERBOSE=1 shows that it
actually uses the proper include dirs.
The problem is with libminifi/test/rocksdb-tests/RepoTests.cpp. It includes
extensions/rockdb-repos/FlowFileRecord.h, which in turn includes the rocksdb
headers and FlowFileRecord's destructor is defined in it.
That means that the destructor is interpreted and compiled under
libminifi/test/rocksdb-tests/, for which the first include is
/usr/local/include, where it finds the system rocksdb headers, causing the
aforementioned destructor problem.
libminifi/test/rocksdb-tests's CMakeList actually sets
${ROCKSDB_THIRDPARTY_ROOT}/include as a target include directory even if we
don't build rocksdb (which may be problematic if we actually wanted to use
system rocksdb), but it is useless, as /usr/local/include will have precedence.
Even if we completely remove the option to use system rocksdb, any time
/usr/local/include is included before our thirdparty include dir, the same
issue will happen.
I'm not sure what is the best solution for this problem. [~phrocker]?
> MacOS build uses RocksDB from brew, if installed, causing segfaults
> -------------------------------------------------------------------
>
> Key: MINIFICPP-824
> URL: https://issues.apache.org/jira/browse/MINIFICPP-824
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
> Reporter: Daniel Bakai
> Assignee: Daniel Bakai
> Priority: Major
>
> If RocksDB is installed from brew, libminifi/test/rocksdb-tests/RepoTests
> segfaults, because of a wrong call to rocksdb::DBImpl's destructor (instead
> of the destructor, an another member function is called).
> It seems like somehow the shipped and the system versions mix up, probably
> causing an ODR violation and ultimately the segfault. (Or the version shipped
> in brew is _very_ incompatible.)
> After RocksDB was uninstalled from brew, and minifi was rebuilt, the test ran
> correctly.
> This might affect other platforms as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
