[
https://issues.apache.org/jira/browse/KUDU-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3776:
--------------------------------
Code Review: http://gerrit.cloudera.org:8080/24272
> Build failure in gperftools 3rd-party component under certain conditions
> ------------------------------------------------------------------------
>
> Key: KUDU-3776
> URL: https://issues.apache.org/jira/browse/KUDU-3776
> Project: Kudu
> Issue Type: Bug
> Reporter: Alexey Serbin
> Assignee: Alexey Serbin
> Priority: Major
>
> The gperftools 3rd-party component sometimes fails to build with an error
> like below:
> {noformat}
> libtool: install: /usr/bin/install -c .libs/libtcmalloc_and_profiler.a
> ./thirdparty/installed/uninstrumented/lib/libtcmalloc_and_profiler.a
> libtool: install: chmod 644
> ./thirdparty/installed/uninstrumented/lib/libtcmalloc_and_profiler.a
> libtool: install: ranlib
> ./thirdparty/installed/uninstrumented/lib/libtcmalloc_and_profiler.a
> ranlib: ./thirdparty/installed/uninstrumented/lib/libtcmalloc_and_profiler.a:
> Error reading libtcmalloc_internal_la-malloc_hook.o: File truncated
> make[1]: *** [Makefile:3718: install-libLTLIBRARIES] Error 1
> make[1]: Leaving directory './thirdparty/build/gperftools-2.13'
> make: *** [Makefile:7602: install-am] Error 2
> {noformat}
> The archive library might be any of the gperftools archive libraries
> installed under {{$KUDU_HOME/thirdparty/installed/uninstrumented/lib}}. Upon
> inspection after the error was reported, the object file in question turned
> to be non-truncated, and the archive library under the build directory itself
> is also solid and not compromised in any way: the {{ar}} utility and
> {{ranlib}} both run perfectly on the archive library in the build directory.
> This is most easily reproducible on a 3rd-party build directory that already
> contains gperftools built and installed, but the build starts because of
> necessity to build some other 3rd-party component, and gperftools is re-built
> by dependency. Impala reported this happening on rare cases on a clean
> workspace. In my case, it happened on a RHEL8.8 x86_64 machine, and I could
> reproduce it 100% of the times when keeping the old build of gperftools in
> {{$KUDU_HOME/thirdparty/build}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
