Tarantool development patches archive
 help / color / mirror / Atom feed
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.

  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