From: Cyrill Gorcunov <gorcunov@gmail.com> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: Mons Anderson <v.perepelitsa@corp.mail.ru>, tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v4 3/4] crash: move fatal signal handling in Date: Tue, 15 Dec 2020 11:16:45 +0300 [thread overview] Message-ID: <20201215081645.GB983198@grain> (raw) In-Reply-To: <2a91ad22-6cd3-0bdd-78ef-203bd4b48a8d@tarantool.org> On Mon, Dec 14, 2020 at 11:54:23PM +0100, Vladislav Shpilevoy wrote: > > + > > +#ifdef TARGET_OS_LINUX > > +#ifndef __x86_64__ > > +# error "Non x86-64 architectures are not supported" > > +#endif > > +struct crash_greg { > > 1. What is 'g' in 'greg'? G(eneral). > > +#endif /* TARGET_OS_LINUX */ > > 2. Perhaps you could reduce number of #ifdef-#endif > if you would define struct crash_greg as an empty > struct for all the other platforms. Then you wouldn't > need the TARGET_OS_LINUX check inside of crash_info. > But up to you. I thought about it, but you know on other OSes there might be different names for these registers (greg name comes from inside of the kernel) so I stick to OS specifics to be more clear. > > +static struct crash_info { > > + /** > > + * These two are mostly useless as being > > + * plain addresses but keep for backward > > + * compatibility. > > 3. Why don't you say the same about 'siaddr'? It is also > just a plain address. The other members are exported to report while these two are printed in local console only. To be honest I don't see any reason in these two members but I kept them to not break backward compatibility. > > +#ifdef ENABLE_BACKTRACE > > + /* > > 4. We usually use /** in out-of-function comment's > first line. This comment is not a part of doxygen, I left it this way intentionally. This comment for internal use. > > > + * 4K of memory should be enough to keep the backtrace. > > + * In worst case it gonna be simply trimmed. > > + */ > > + char backtrace_buf[4096]; > > 5. This is a functional change. Previously for the backtrace > we used the static buffer. > > 1) Why did you change it? Because the buffer is used between the calls, iow it filled once and then passed to plain report to the console and then to json encoding. And keeping data in static buffer between the calls is very bad idea, it bounds calls to the context. I'm ready to spend 4K per instance for this. We can shrink the value down to 1K if you prefer but keeping static buffer between the calls definitely is not an option. > 2) Why isn't it in a separate commit? As I told you, it is really > hard to extract what did you change in a ~460 lines patch titled as > 'move' to check if it does not break anything or is even needed. > Please, don't make it harder. Vlad, I remember this. The problem is that if I would do interdiff the result will be simply unreadable (believe me, I tried). This is why I sent the whole new patch instead. I reworked the patch too much. > Also print_backtrace() becomes unused after your patch. Not really [cyrill@grain tarantool.git] git grep -n print_backtrace src/lib/core/backtrace.cc:436:print_backtrace(void) src/lib/core/backtrace.cc:449: print_backtrace(); src/lib/core/backtrace.h:46:void print_backtrace(void); src/lua/init.c:367: print_backtrace(); It is still suitable own handler, no?
next prev parent reply other threads:[~2020-12-15 8:16 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-10 16:18 [Tarantool-patches] [PATCH v4 0/4] crash: implement sending feedback Cyrill Gorcunov 2020-12-10 16:18 ` [Tarantool-patches] [PATCH v4 1/4] util: introduce strlcpy helper Cyrill Gorcunov 2020-12-11 7:34 ` Serge Petrenko 2020-12-11 7:58 ` Serge Petrenko 2020-12-11 10:04 ` Cyrill Gorcunov 2020-12-11 11:07 ` Serge Petrenko 2020-12-11 11:38 ` Cyrill Gorcunov 2020-12-14 22:54 ` Vladislav Shpilevoy 2020-12-14 22:54 ` Vladislav Shpilevoy 2020-12-15 8:47 ` Cyrill Gorcunov 2020-12-10 16:18 ` [Tarantool-patches] [PATCH v4 2/4] backtrace: allow to specify destination buffer Cyrill Gorcunov 2020-12-11 7:50 ` Serge Petrenko 2020-12-10 16:18 ` [Tarantool-patches] [PATCH v4 3/4] crash: move fatal signal handling in Cyrill Gorcunov 2020-12-11 9:31 ` Serge Petrenko 2020-12-11 10:38 ` Cyrill Gorcunov 2020-12-11 11:12 ` Serge Petrenko 2020-12-14 22:54 ` Vladislav Shpilevoy 2020-12-15 8:16 ` Cyrill Gorcunov [this message] 2020-12-20 14:48 ` Vladislav Shpilevoy 2020-12-20 15:49 ` Cyrill Gorcunov 2020-12-20 16:07 ` Vladislav Shpilevoy 2020-12-20 16:58 ` Cyrill Gorcunov 2020-12-20 15:45 ` Vladislav Shpilevoy 2020-12-10 16:18 ` [Tarantool-patches] [PATCH v4 4/4] crash: report crash data to the feedback server Cyrill Gorcunov 2020-12-11 12:57 ` Serge Petrenko 2020-12-12 16:19 ` Cyrill Gorcunov 2020-12-12 17:07 ` Cyrill Gorcunov 2020-12-14 9:41 ` Serge Petrenko 2020-12-14 22:54 ` Vladislav Shpilevoy 2020-12-16 11:16 ` Cyrill Gorcunov 2020-12-16 20:31 ` Cyrill Gorcunov 2020-12-20 15:16 ` Vladislav Shpilevoy 2020-12-20 18:26 ` Cyrill Gorcunov 2020-12-20 14:48 ` Vladislav Shpilevoy 2020-12-20 18:21 ` Cyrill Gorcunov 2020-12-20 18:41 ` Vladislav Shpilevoy 2020-12-20 19:16 ` Cyrill Gorcunov 2020-12-21 17:01 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201215081645.GB983198@grain \ --to=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.perepelitsa@corp.mail.ru \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v4 3/4] crash: move fatal signal handling in' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox