Alexey Serbin created KUDU-3776:
-----------------------------------
Summary: 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
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)
