[
https://issues.apache.org/jira/browse/KUDU-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18078479#comment-18078479
]
ASF subversion and git services commented on KUDU-3776:
-------------------------------------------------------
Commit eebdd0d33b6174df6617b5cef07f32085ac8c475 in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=eebdd0d33 ]
KUDU-3776 fix sporadic gperftools build failure
I had a build machine where KUDU-3776 was 100% reproducible starting with
a particular state of the 3rd-party workspace. Without spending time on
the detailed RCA, I put together a fix that worked 100% for me at that
machine, while the build would fail 100% of the times if starting with
a particular state of the workspace without this patch.
One of the regular suspects is the incorrect tracking of transitive
dependencies, but I didn't see much sense in getting to the bottom of the
issue, given the new way of building gperftools is more consistent with
the build recipe provided in the top-level INSTALL file.
Change-Id: Ie8c26bcc3c2625741cd05b3cc459159434e9d60b
Reviewed-on: http://gerrit.cloudera.org:8080/24272
Tested-by: Kudu Jenkins
Reviewed-by: Zoltan Martonka <[email protected]>
Reviewed-by: Abhishek Chennaka <[email protected]>
Reviewed-by: Marton Greber <[email protected]>
> 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)
