From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com> 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: Sun, 20 Dec 2020 17:07:14 +0100 [thread overview] Message-ID: <ad136751-8915-661e-c654-fe394dac0e11@tarantool.org> (raw) In-Reply-To: <20201220154914.GA3139@grain> On 20.12.2020 16:49, Cyrill Gorcunov wrote: > On Sun, Dec 20, 2020 at 03:48:11PM +0100, Vladislav Shpilevoy wrote: >>>>> +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. >> >> This one also is printed to local console only. So the >> question is the same, why don't you call it also a useless >> plain address? > > Because context_addr and siginfo_addr comes from a signal frame > and they are uselesss if you have no real crash dump under your > hands. You simply cant do anything with them and I don't understand > why we're printing them and who needs them. > > In turn siaddr points to the memory caused the signal to trigger > and this address a way more suitable for understanding what > is happeneing than context and siginfo. > > I can simply drop the comment if you dont like it. No. I am trying to understand why one plain address matters, and the others are not. But now I think I understood, thanks. Keep the comment. >> commit. And this commit is not atomic. Also I know when a patch is >> easy to follow and easy to review. This one isn't. Because I constantly >> need to look for changes you did among hundreds of lines of refactoring. >> >> Please, split the independent changes into separate commits so as they >> could be properly reviewed and the changes could be justified in the >> commit messages. > > Currently the commit is big enough because I jump into signal handling > in one pass. If you prefer I can split the series in more small changes. > Or you mean the updates over previsous series should be changes in small > steps as a separate commits? No, I don't mean commits with review fixes. I mean the patch commits. Currently you have a patch that moves signal handling to crash.c AND it also changes backtrace to use a 4KB buffer instead of the static buffer. These 2 changes (move and backtrace buffer source change) are not related. Therefore it is not correct to put them into 1 commit. It does not matter in which order you will do these 2 changes, but one should be about move only, and the other one about backtrace buffer update only.
next prev parent reply other threads:[~2020-12-20 16:07 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 2020-12-20 14:48 ` Vladislav Shpilevoy 2020-12-20 15:49 ` Cyrill Gorcunov 2020-12-20 16:07 ` Vladislav Shpilevoy [this message] 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=ad136751-8915-661e-c654-fe394dac0e11@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.perepelitsa@corp.mail.ru \ --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