[ 
https://issues.apache.org/jira/browse/KUDU-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Serbin reassigned KUDU-3776:
-----------------------------------

    Assignee: Alexey Serbin

> 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)

Reply via email to