An exception occurs after multi-match statement executed multiple times

[czpmango]

Describe the bug (required)
An exception occurs after multi-match statement executed multiple times.

Your Environments (required)
nebula 3.1.0

How To Reproduce(required)

(root@nebula) [nba]> match (v:player) where v.player.name == "Tim Duncan" MATCH (v)-[e:serve]->(n:team) return v 
+-------------------------------------------------------------------------------------------------------------+
| v                                                                                                           |
+-------------------------------------------------------------------------------------------------------------+
| ("Tim Duncan" :player{age: 42, name: "Tim Duncan"} :bachelor{name: "Tim Duncan", speciality: "psychology"}) |
+-------------------------------------------------------------------------------------------------------------+
Got 1 rows (time spent 21388/21784 us)

Fri, 15 Jul 2022 10:09:01 CST

(root@nebula) [nba]> match (v:player) where v.player.name == "Tim Duncan" MATCH (v)-[e:serve]->(n:team) return v
+-------------------------------------------------------------------------------------------------------------+
| v                                                                                                           |
+-------------------------------------------------------------------------------------------------------------+
| ("Tim Duncan" :player{age: 42, name: "Tim Duncan"} :bachelor{name: "Tim Duncan", speciality: "psychology"}) |
+-------------------------------------------------------------------------------------------------------------+
Got 1 rows (time spent 19474/19842 us)

Fri, 15 Jul 2022 10:09:03 CST

(root@nebula) [nba]> match (v:player) where v.player.name == "Tim Duncan" MATCH (v)-[e:serve]->(n:team) return v
2022/07/15 10:09:04 Loop error, failed to reconnect, failed to open transport, error: dial tcp 127.0.0.1:1774: connect: connection refused

The above phenomenon is reproduced in debug mode, and graphd will crash. If in release mode, it will not crash but the query result is empty.

Expected behavior
Get the correct result.

Additional context
This bug is a stable recurrence.

[czpmango]

Part of the core stack is as follows:

#0  0x0000000004c290a6 in nebula::Value::toString[abi:cxx11]() const (this=0x0) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/Value.cpp:1709
#1  0x0000000003880266 in nebula::operator<< (os=..., value=<error reading variable: Cannot access memory at address 0x0>) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/Value.h:502
#2  0x0000000004c3c2cb in nebula::Vertex::toString[abi:cxx11]() const (this=0x0) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/Vertex.cpp:66
#3  0x0000000004c29603 in nebula::Value::toString[abi:cxx11]() const (this=0x7fe0362379a0) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/Value.cpp:1759
#4  0x0000000004c3f0b2 in nebula::List::<lambda(const auto:4&)>::operator()<nebula::Value>(const nebula::Value &) const (__closure=0x7fe0410e9b27, v=kEmpty) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/List.cpp:17
#5  0x0000000004c3f00e in std::transform<__gnu_cxx::__normal_iterator<const nebula::Value*, std::vector<nebula::Value> >, __gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char>*, std::vector<std::__cxx11::basic_string<char> > >, nebula::List::toString() const::<lambda(const auto:4&)> >(__gnu_cxx::__normal_iterator<nebula::Value const*, std::vector<nebula::Value, std::allocator<nebula::Value> > >, __gnu_cxx::__normal_iterator<nebula::Value const*, std::vector<nebula::Value, std::allocator<nebula::Value> > >, __gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, nebula::List::<lambda(const auto:4&)>) (__first=kEmpty, __last=kEmpty, __result="", __unary_op=...) at /usr/include/c++/9/bits/stl_algo.h:4343
#6  0x0000000004c3ec28 in nebula::List::toString[abi:cxx11]() const (this=0x7fdff2470000) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/List.cpp:18
#7  0x000000000358f0ae in nebula::operator<< (os=..., l=...) at /home/kyle.cao/workspace/fork/nebula/src/common/datatypes/List.h:91
#8  0x00000000038a4239 in nebula::graph::SequentialIter::getColumn (this=0x7fe035e203f0, col="v") at /home/kyle.cao/workspace/fork/nebula/src/graph/context/Iterator.cpp:685
#9  0x00000000036e4518 in nebula::graph::ArgumentExecutor::execute (this=0x7fe035a2f180) at /home/kyle.cao/workspace/fork/nebula/src/graph/executor/logic/ArgumentExecutor.cpp:26
#10 0x0000000003882184 in nebula::graph::AsyncMsgNotifyBasedScheduler::execute (this=0x7fe03620f3c0, executor=0x7fe035a2f180) at /home/kyle.cao/workspace/fork/nebula/src/graph/scheduler/AsyncMsgNotifyBasedScheduler.cpp:221
#11 0x0000000003886dbf in nebula::graph::AsyncMsgNotifyBasedScheduler::<lambda(auto:182&&)>::operator()<std::vector<nebula::Status> >(std::vector<nebula::Status, std::allocator<nebula::Status> > &&) (__closure=0x7fe035a0ed10, t=...) at /home/kyle.cao/workspace/fork/nebula/src/graph/scheduler/AsyncMsgNotifyBasedScheduler.cpp:158
#12 0x0000000003883214 in folly::futures::detail::<lambda()>::operator()(void) const (this=0x7fe0410ea0c0) at /home/kyle.cao/3rd/include/folly/futures/Future-inl.h:101
#13 0x0000000003886e54 in folly::futures::detail::InvokeResultWrapperBase<folly::Future<nebula::Status> >::wrapResult<folly::futures::detail::wrapInvoke(folly::Try<T>&&, F&&) [with T = std::vector<nebula::Status>; F = nebula::graph::AsyncMsgNotifyBasedScheduler::runExecutor(std::vector<folly::Future<nebula::Status> >&&, nebula::graph::Executor*, folly::Executor*) const::<lambda(auto:182&&)>]::<lambda()> >(folly::futures::detail::<lambda()>) (fn=...) at /home/kyle.cao/3rd/include/folly/futures/Future-inl.h:73

[czpmango]

not sure whether it's related to #4424 , which contains two matches.

Please describe this issue in detail, I did not get a reproduced statement. Are there some error logs?

[czpmango]

After my verification, it has nothing to do with issue #4424 .

[eddieHRS]

Will this bug be fixed in version 3.2.0 ?

[czpmango]

@Sophie-Xie

[Sophie-Xie]

not sure whether it's related to #4424 , which contains two matches.

Please describe this issue in detail, I did not get a reproduced statement. Are there some error logs?

Sorry for this bug. It's a little hard to fix it, and we will fix it in 3.2.1 ASAP.

[eddieHRS]

Ok

[czpmango]

Fixed.