<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre><span class="q5WsiM0 q5WsiM1_q5Wsiwu q5WsiGG_q5WsiGF q5WsiM0_q5WsiMU q5WsiM0_q5WsiKY q5WsiM0_q5Wsicx" style="max-width: 2150px; --left-column-width:232px; --right-column-width:248px; --sidebar-column-width:320px;">Hi! Thanks for the review!</span></pre>
<div class="moz-cite-prefix">
<pre>On 6/7/21 11:28 AM, Cyrill Gorcunov wrote:</pre>
</div>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<pre class="moz-quote-pre" wrap="">On Fri, Jun 04, 2021 at 02:13:10PM +0300, Egor Elchinov via Tarantool-patches wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">From: Egor2001 <a class="moz-txt-link-rfc2396E" href="mailto:elchinov.es@gmail.com"><elchinov.es@gmail.com></a>
For now fiber creation backtrace is stored
in the separate subtable of fiber.info
called backtrace_parent for convenience.
Lua stacks of fiber creation
aren't preserved in backtrace yet because
of need to somehow handle parent Lua state
inside the child fiber for this sake.
Backtrace caching and demangling
aren't present yet too as this is a
proof-of-concept implementation.
Needed for: #4002
---
+/**
+ * Collect up to `limit' IP register values
+ * for frames of the current stack into `ip_buf'.
+ * Must be by far faster than usual backtrace according to the
+ * libunwind doc for unw_backtrace().
+ */
+void
+fast_trace_collect(void **ip_buf, int limit)
+{
+ memset(ip_buf, 0, limit * sizeof(*ip_buf));
+ unw_backtrace(ip_buf, limit);
+}
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This is not guaranteed to be faster, so I would name it
backtrace_collect_ip. Also you have to mark it as NOINLINE,
otherwise IPs gonna be screwed. Moreover you put a special
offset into IPs resolving inside fast_trace_foreach to hide
the fast_trace_collect call itself, I think we should be
very loud about, otherwise other people might get confusing
what we're doing with frame numbers and why we skip the first
frame.
</pre>
</blockquote>
<pre>Thanks, fixed.
</pre>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<pre class="moz-quote-pre" wrap="">
Also I personally not sure if we must collect fiber's creation
backtrace for every fiber in a system even if we never need it,
I'm pretty sure that backtrace is very far from cheap. But I
left it up to you to decide. I guess we might need some kind
of dynamic settings similar to fiber_top?
</pre>
</blockquote>
<pre>Good point, I've consulted with Alexander Lyapunov and
it was decided to add a dynamic setting enabling this feature.
</pre>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">+void
+fast_trace_foreach(backtrace_cb cb, void **ip_buf, int limit, void *cb_ctx)
+{
+ static __thread char proc_name[BACKTRACE_NAME_MAX];
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Why do you need it be per thread? There must be very strong reason why some
data is put into TLS.
</pre>
</blockquote>
<pre>Thanks, fixed.
</pre>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">+ int frame_no = 0;
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This is shor routine and I think plain `n` would be more than enough.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">For now that's true, but `frame_no` name was chosen mostly
for consistency with the present `backtrace` routines.
Also, routine will be more complicated after addition of
DARWIN `#ifdef` and demangling support.
</pre>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">+ unw_word_t ip = 0, offset = 0;
+ unw_proc_info_t pi;
+ int ret = 0;
+ char* proc = NULL;
+
+ unw_accessors_t* acc = unw_get_accessors(unw_local_addr_space);
+ assert(acc);
+
+ for (frame_no = 0; frame_no < limit && ip_buf[frame_no] != NULL;
+ ++frame_no) {
+ ip = (unw_word_t)ip_buf[frame_no];
+ if (acc->get_proc_name == NULL) {
+ ret = unw_get_proc_info_by_ip(unw_local_addr_space,
+ ip, &pi, NULL);
+ offset = ip - pi.start_ip;
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Why proc is left untouched here? it may carry old value from
previous acc->get_proc_name call, is it ok?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It's ok, because if `proc` gets non-NULL value then
`acc->get_proc_name` routine is present in the system and
this part of code will never be called.
Otherwise `proc` can't be retrieved by the
libunwind API and has to be NULL.
</pre>
<blockquote type="cite" cite="mid:YL3YnEUJI2skMHyT@grain">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">+ } else {
+ ret = acc->get_proc_name(unw_local_addr_space, ip,
+ proc_name, sizeof(proc_name),
+ &offset, NULL);
+ proc = proc_name;
+ }
+
+ if (ret != 0 || (frame_no > 0 &&
+ cb(frame_no - 1, (void *)ip, proc,
+ (size_t)offset, cb_ctx) != 0))
+ break;
+ }
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Egor, I think this is very good PoC code! Here is the diff I made
on top of your patch to share ideas. Not insisting anyhow on code
refactoring, vars renaming and etc.
Also I CC Vlad, since he might have own vision on overall code design.
And since Vlad is the final line before code goes upstream better wait
for his opinion.
</pre>
</blockquote>
<pre>Thanks a lot for your diff!
Also I haven't decided yet how to grab Lua stacks of
fiber creation in a cheap way.
I would be glad for any suggestions on this issue too.
</pre>
</body>
</html>