Storage core

[Shylock-Hg]

Please check the FAQ documentation before raising an issue

Please check the FAQ documentation and old issues before raising an issue in case someone has asked the same question that you are asking.

Describe the bug (required)

➜  server_2021-11-15T16-31-38 git:(feature/view-vertices-edges) ✗ lldb -c core.108534 ./bin/nebula-storaged 
(lldb) target create "./bin/nebula-storaged" --core "core.108534"
Core file '/home/shylock.huang/nebula/build/server_2021-11-15T16-31-38/core.108534' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'nebula-storaged', stop reason = signal SIGSEGV
  * frame #0: 0x00000000026606a5 nebula-storaged`nebula::storage::QueryUtils::readValue(reader=0x00007f335a1fae90, propName="type", field=0x0000000000000000) at QueryUtils.h:58
    frame #1: 0x00000000027e2a69 nebula-storaged`nebula::storage::IndexVertexScanNode::decodeFromBase(this=0x00007f3350f30380, key="\x01\x02", value="\b") at IndexVertexScanNode.cpp:99
    frame #2: 0x00000000027cd5c1 nebula-storaged`nebula::storage::IndexScanNode::doNext(this=0x00007f3350f30380) at IndexScanNode.cpp:438
    frame #3: 0x000000000277b865 nebula-storaged`nebula::storage::IndexNode::next(this=0x00007f3350f30380) at IndexNode.h:146
    frame #4: 0x00000000027c3296 nebula-storaged`nebula::storage::IndexProjectionNode::doNext(this=0x00007f33330bdcc0) at IndexProjectionNode.cpp:38
    frame #5: 0x000000000277b865 nebula-storaged`nebula::storage::IndexNode::next(this=0x00007f33330bdcc0) at IndexNode.h:146
    frame #6: 0x00000000027c1cfe nebula-storaged`nebula::storage::IndexLimitNode::doNext(this=0x00007f334c26d800) at IndexLimitNode.cpp:32
    frame #7: 0x000000000277b865 nebula-storaged`nebula::storage::IndexNode::next(this=0x00007f334c26d800) at IndexNode.h:146
    frame #8: 0x0000000002778f79 nebula-storaged`nebula::storage::LookupProcessor::runInSingleThread(this=0x00007f3384a38f00, parts=size=9, plan=<unavailable>) at LookupProcessor.cpp:169
    frame #9: 0x0000000002777369 nebula-storaged`nebula::storage::LookupProcessor::doProcess(this=0x00007f3384a38f00, req=0x00007f33319a8d20) at LookupProcessor.cpp:61
    frame #10: 0x0000000002781eb8 nebula-storaged`nebula::storage::LookupProcessor::process(this=0x00007f33319a8d20)::$_0::operator()() const at LookupProcessor.cpp:28
    frame #11: 0x0000000002781de0 nebula-storaged`void folly::detail::function::FunctionTraits<void ()>::callBig<nebula::storage::LookupProcessor::process(p=0x00007f336d2c9790)::$_0>(folly::detail::function::Data&) at Function.h:385
    frame #12: 0x000000000421e607 nebula-storaged`virtual thunk to apache::thrift::concurrency::FunctionRunner::run() + 151
    frame #13: 0x0000000004359af3 nebula-storaged`apache::thrift::concurrency::ThreadManager::Impl::Worker::run() + 339
    frame #14: 0x000000000435d74d nebula-storaged`apache::thrift::concurrency::PthreadThread::threadMain(void*) + 205
    frame #15: 0x00007f33902ba58e libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:486
    frame #16: 0x00007f33901e9513 libc.so.6`__GI___clone at clone.S:95

Your Environments (required)

• OS: uname -a
• Compiler: g++ --version or clang++ --version
• CPU: lscpu
• Commit id (e.g. a3ffc7d8)

How To Reproduce(required)

Steps to reproduce the behavior:

Run tck

Expected behavior

A clear and concise description of what you expected to happen.

Additional context

Provide logs and configs, or any other context to trace the problem.

[critical27]

Which tck test case? Also upload the log...

[Shylock-Hg]

Which tck test case? Also upload the log...

Don't know..

[cangfengzhs]

How to reproduce?

[Shylock-Hg]

How to reproduce?

Run tck:
make -C ../tests up
make -C ../tests tck
make -C ../tests tck
...
until core.

[cangfengzhs]

How to reproduce?

Run tck: make -C ../tests up make -C ../tests tck make -C ../tests tck ... until core.

It did not reproduce successfully. In addition, according to the coredump stack, storage is a failure when reading a tag containing a field named prop, but there is no such case in tck.

[Shylock-Hg]

How to reproduce?

Run tck: make -C ../tests up make -C ../tests tck make -C ../tests tck ... until core.

It did not reproduce successfully. In addition, according to the coredump stack, storage is a failure when reading a tag containing a field named prop, but there is no such case in tck.

But in coredump, the propName is "type".

[cangfengzhs]

I found it, IndexTest AlterSchemaTest.

 CREATE TAG INDEX alter_index ON alter_tag(id);  // schemaVersion=1
 ALTER TAG alter_tag ADD (type int); // SchemaVersion=2

In this case, after ALTER statement, there is a certain probability that the graph sees version2 but storage can only see version1.This causes storage to obtain a null pointer when obtaining the type property. I will add a check to the storage first to avoid this problem.

A better suggestion is that we may implement a more complete DDL process in a distributed system, just like Google F1.After all, in addition to this bug, we have many other DDL-related issues, such as dropping a property or Schema.