You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (JIRA)" <ji...@apache.org> on 2016/11/11 06:41:58 UTC
[jira] [Comment Edited] (KUDU-1745) Kudu causes Impala to crash
under stress
[ https://issues.apache.org/jira/browse/KUDU-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15656315#comment-15656315 ]
Alexey Serbin edited comment on KUDU-1745 at 11/11/16 6:41 AM:
---------------------------------------------------------------
Probably, that was out-of-memory case -- if I'm not mistaken, the attached log shows
{noformat}
MemTotal: 15238768 kB
MemFree: 247332 kB
Buffers: 211372 kB
Cached: 4779972 kB
SwapCached: 0 kB
Active: 12002096 kB
Inactive: 2406436 kB
Active(anon): 9417892 kB
Inactive(anon): 140 kB
Active(file): 2584204 kB
Inactive(file): 2406296 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
{noformat}
If so, then most likely that was std::bad_alloc thrown and then the C++ run-time called the standard handler for unhandled exceptions. But I don't understand why it's SIGSEGV, not SIGABRT.
was (Author: aserbin):
Probably, that was out-of-memory case -- if I'm not mistaken, the attached log shows
{noformat}
MemTotal: 15238768 kB
MemFree: 247332 kB
Buffers: 211372 kB
Cached: 4779972 kB
SwapCached: 0 kB
Active: 12002096 kB
Inactive: 2406436 kB
Active(anon): 9417892 kB
Inactive(anon): 140 kB
Active(file): 2584204 kB
Inactive(file): 2406296 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
{noformat}
If so, then most likely that was std::bad_alloc thrown and then the C++ run-time called the standard handler for unhandled exceptions.
> Kudu causes Impala to crash under stress
> ----------------------------------------
>
> Key: KUDU-1745
> URL: https://issues.apache.org/jira/browse/KUDU-1745
> Project: Kudu
> Issue Type: Bug
> Reporter: Taras Bobrovytsky
> Priority: Critical
> Attachments: hs_err_pid7761.log, stacks.out
>
>
> There were over 200 queries running, about half of which were selects and the rest were upsert and delete queries.
> There was a crash after a few minutes with the following stack trace:
> {code}
> Stack: [0x00007f1629c93000,0x00007f162a694000], sp=0x00007f162a6922b0, free space=10236k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libstdc++.so.6+0xc5018] std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&)+0x8
> C [libkudu_client.so.0+0x6f662] _ZNSt6vectorIPN4kudu6client9KuduErrorESaIS3_EE19_M_emplace_back_auxIIS3_EEEvDpOT_+0x1dd2
> C [libkudu_client.so.0+0x4c872] _init+0xd022
> C [libkudu_client.so.0+0x4c9d6] _init+0xd186
> C [libkudu_client.so.0+0x70775] _ZNSt6vectorIPN4kudu6client9KuduErrorESaIS3_EE19_M_emplace_back_auxIIS3_EEEvDpOT_+0x2ee5
> C [libkudu_client.so.0+0x754d9] _ZNSt6vectorIPN4kudu6client9KuduErrorESaIS3_EE19_M_emplace_back_auxIIS3_EEEvDpOT_+0x7c49
> C [libkudu_client.so.0+0xc9be0] kudu::client::KuduUpsert::~KuduUpsert()+0x2ae30
> C [libkudu_client.so.0+0xc9eb2] kudu::client::KuduUpsert::~KuduUpsert()+0x2b102
> C [libkudu_client.so.0+0xcc73d] _ZNSt6vectorIN4kudu5SliceESaIS1_EE19_M_emplace_back_auxIIS1_EEEvDpOT_+0x123d
> C [libkudu_client.so.0+0xbe405] kudu::client::KuduUpsert::~KuduUpsert()+0x1f655
> C [libkudu_client.so.0+0xcdc0c] _ZNSt6vectorIN4kudu5SliceESaIS1_EE19_M_emplace_back_auxIIS1_EEEvDpOT_+0x270c
> C [libkudu_client.so.0+0x25ec1b] _ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE22_M_emplace_hint_uniqueIJRKSt21piecewise_construct_tSt5tupleIJRS1_EESD_IJEEEEESt17_Rb_tree_iteratorIS2_ESt23_Rb_tree_const_iteratorIS2_EDpOT_+0x311b
> C [libkudu_client.so.0+0x262324] _ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE22_M_emplace_hint_uniqueIJRKSt21piecewise_construct_tSt5tupleIJRS1_EESD_IJEEEEESt17_Rb_tree_iteratorIS2_ESt23_Rb_tree_const_iteratorIS2_EDpOT_+0x6824
> T_+0x558a
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)