[
https://issues.apache.org/jira/browse/KUDU-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3776:
--------------------------------
Description:
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 was
also solid and not compromised in any way: the {{ar}} utility and {{ranlib}}
both ran perfectly on the archive library in the build directory.
It turned to be easier to reproducible on a 3rd-party build directory that
already contained gperftools built and installed, but gperftools would be built
again because of the necessity to build some other 3rd-party component, where
gperftools would be re-built by dependency. Impala people reported this
happening on rare cases on a clean workspace as well. 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}}.
was:
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}}.
> 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
> was also solid and not compromised in any way: the {{ar}} utility and
> {{ranlib}} both ran perfectly on the archive library in the build directory.
> It turned to be easier to reproducible on a 3rd-party build directory that
> already contained gperftools built and installed, but gperftools would be
> built again because of the necessity to build some other 3rd-party component,
> where gperftools would be re-built by dependency. Impala people reported
> this happening on rare cases on a clean workspace as well. 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)
