[
https://issues.apache.org/jira/browse/IMPALA-14876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071553#comment-18071553
]
ASF subversion and git services commented on IMPALA-14876:
----------------------------------------------------------
Commit 402e07c64620d142833fd5d0588010fc5d257620 in impala's branch
refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=402e07c64 ]
IMPALA-14876: Use char* for thread name in impala::Thread::SuperviseThread
impala::Thread::SuperviseThread() runs most of the backend threads. Its
first parameter is the thread name in std::string type. Backtraces in
pstack/gdb usually omit its value by just showing "name=...".
The thread name is important to find the thread of a given fragment
instance, e.g.,
"exec-finstance (finst:594ed4f65014cbd3:4bae840b00000001)",
"query-state-594ed4f65014cbd3:4bae840b00000000",
"scanner-thread (finst:594ed4f65014cbd3:4bae840b00000001, plan-node-id:0,
thread-idx:2)".
This patch improves this by changing the parameter type of 'name' to
const char* so the string can be actually printed. It's unexpected /
unsafe for SuperviseThread() to keep refering to parameters passed by
reference or pointer to it. So a thread local string is used to copy the
thread name and 'name' pointer is updated to point to it. See JIRA
comments for some examples.
Note that I have to add __attribute__((optimize("O0"))) to the method to
avoid 'name' being printed as "<optimized out>". This is a GCC
attribute. For clang, we use [[clang::optnone]].
Tests
- Manually tested pstacks on Rocky 9.7 when running a slow query:
select count(*) from functional.alltypes where sleep(100) < id;
Change-Id: I7fa831d4efd7d8665f9c69fcea960e8e1c47aa2b
Reviewed-on: http://gerrit.cloudera.org:8080/24171
Reviewed-by: Michael Smith <[email protected]>
Reviewed-by: Jason Fehr <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Use const char* for thread name in impala::Thread::SuperviseThread
> ------------------------------------------------------------------
>
> Key: IMPALA-14876
> URL: https://issues.apache.org/jira/browse/IMPALA-14876
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Reporter: Quanlong Huang
> Assignee: Quanlong Huang
> Priority: Critical
> Attachments: new-pstack.txt
>
>
> impala::Thread::SuperviseThread() runs most of the backend threads. Its first
> parameter is the thread name:
> {code:cpp}
> static void SuperviseThread(const std::string& name, const std::string&
> category,
> const ThreadFunctor& functor, const ThreadDebugInfo* parent_thread_info,
> Promise<int64_t>* thread_started);{code}
> In backtraces printed in pstack/gdb, the thread name is usually omitted as
> "name=...", e.g.
> {noformat}
> #39 impala::Thread::SuperviseThread(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
> > const&, boost::function<void ()>, impala::ThreadDebugInfo const*,
> impala::Promise<long, (impala::PromiseMode)0>*) (name=..., category=...,
> functor=..., parent_thread_info=0x7f6bffa027f0,
> thread_started=0x7f6bffa01ac0) at thread.cc:360{noformat}
> It'd be helpful to print the thread name so we can directly find the thread
> of a given fragment instance. The first option is making the thread name be
> shown correctly:
> {noformat}
> Thread 1045 (Thread 0x7ff184860640 (LWP 1395025) "reacquire threa"):{noformat}
> However, pstack typically pulls the thread name from
> /proc/<pid>/task/<tid>/comm. Since the kernel only stores 15 characters
> there, pstack can only show 15 characters. That's not enough for fragment
> instance ids.
> The second option is changing the 'name' parameter type to const char* and
> make sure it's not optimized out. Then pstack will print its value in the
> backtrace.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
