[
https://issues.apache.org/jira/browse/KUDU-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110249#comment-17110249
]
ASF subversion and git services commented on KUDU-3096:
-------------------------------------------------------
Commit 3a8e9c0f20b801f4d81211c67f26b69152547dc9 in kudu's branch
refs/heads/master from RuiChen
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=3a8e9c0 ]
KUDU-3096: Upgrade libunwind to 1.4.0
libunwind 1.3.1 use malloc in thread stack trace collection,
that cause core dump and potential deadlock between GetThreadStack
and SuperviseThread, GetThreadStack function will try to collect
thread info even if tcmalloc ThreadCache haven't been inited completlly,
the issue happen in ARM64 server. In libunwind 1.4.0, upstream have
fixed malloc issue, so upgrade it.
Change-Id: Icc722cd5e8ed4ed668d279f6ec831e4eeb69f955
Reviewed-on: http://gerrit.cloudera.org:8080/15899
Tested-by: Kudu Jenkins
Reviewed-by: Grant Henke <[email protected]>
> debug-util-test failed sometimes on aarch64: Segmentation fault
> ---------------------------------------------------------------
>
> Key: KUDU-3096
> URL: https://issues.apache.org/jira/browse/KUDU-3096
> Project: Kudu
> Issue Type: Sub-task
> Reporter: huangtianhua
> Assignee: RuiChen
> Priority: Major
>
> I test kudu on aarch64 server based on https://gerrit.cloudera.org/#/c/14964/
> , the test debug-util-test failed sometimes, please see the detail info of
> gdb the core dump file: http://paste.openstack.org/show/791306/
> root@ubuntu:/home/jenkins/workspace/kudu/build/debug# ./bin/debug-util-test
> ......
> W0330 07:30:44.317989 27980 debug-util.cc:405] Leaking SignalData structure
> 0xaaaaf89ed260 after lost signal to thread 28015
> W0330 07:30:44.319747 27980 debug-util.cc:405] Leaking SignalData structure
> 0xaaaaf89ed280 after lost signal to thread 28015
> W0330 07:30:44.319774 27980 debug-util.cc:405] Leaking SignalData structure
> 0xaaaaf89ed2a0 after lost signal to thread 28015
> W0330 07:30:44.326023 27980 debug-util.cc:405] Leaking SignalData structure
> 0xaaaaf89ed2c0 after lost signal to thread 28015
> I0330 07:30:44.336513 27980 debug-util-test.cc:463] Timed out 1410 times
> I0330 07:30:44.336531 27980 debug-util-test.cc:464] Succeeded 13591 times
> [ OK ] DebugUtilTest.TestTimeouts (1002 ms)
> [----------] 9 tests from DebugUtilTest (3049 ms total)
> [----------] 4 tests from DifferentRaces/RaceTest
> [ RUN ] DifferentRaces/RaceTest.TestStackTraceRaces/0
> Segmentation fault (core dumped)
> root@ubuntu:/home/jenkins/workspace/kudu/build/debug# gdb bin/debug-util-test
> core.27980
> GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "aarch64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from bin/debug-util-test...done.
> [New LWP 28016]
> [New LWP 27980]
> [New LWP 27981]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> Core was generated by `./bin/debug-util-test'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 tcmalloc::Sampler::RecordAllocation (k=<optimized out>, this=<optimized
> out>)
> at
> /home/jenkins/workspace/kudu/thirdparty/src/gperftools-2.6.90/src/sampler.h:166
> 166 if (static_cast<size_t>(bytes_until_sample_) < k) {
> [Current thread is 1 (Thread 0xffff86a9b090 (LWP 28016))]
> Sometimes other tests like TestTimeouts are raise segmentation fault either,
> the gdb info are same, have no idea it related with gperftools? Maybe someone
> help us to fix this, thanks very much.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
