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 v3 2/4] errstat: add crash report base code Date: Sat, 5 Dec 2020 22:58:27 +0300 [thread overview] Message-ID: <20201205195827.GC2303@grain> (raw) In-Reply-To: <eff047f4-fdbb-c593-e602-f526001dfbb9@tarantool.org> On Sat, Dec 05, 2020 at 07:33:05PM +0100, Vladislav Shpilevoy wrote: > > | "build": { > > | "major": 2, > > | "minor": 7, > > | "patch": 0, > > 1. Why do you need the version numbers and the 'version' > string both? All can be extracted from 'version' string. Sure we can extract it but I thought this gonna be more convenient 'cause it won't require the reader to split string, extract the major/minor. This is not a problem to drop these fields and leave "version" only if you prefer. I don't mind. > > | }, > > | "signal": { > > | "signo": 11, > > | "si_code": 0, > > | "si_addr": "0x3e800009727", > > | "backtrace": "IzAgIDB4NjMyODhiIGlu..", > > | "timestamp": "0x164ceceac0610ae9", > > 2. Why is timestamp in hex? And why do you need both > hex and string? hex is simply more short form for timestamp, I can put plain integer number if you prefer. as to time string -- the prblem is in local timezone, the timestamp itself doesn't show which tz it is. thus we either have to send tz explicitly or a time string. if you mean to simply drop timestamp and use timestring only I'm ok with this.. > > > | "timestamp_str": "2020-12-02 17:34:20 MSK" > > | } > > | } > > > > Part-of #5261 > > 3. Lets better put the issue link in the end, like we do in 100% > of our patches except when a docbot request is present. Because > we usually look for issue reference in the end, and by putting it > into a random place of a commit message you complicate that > search. Ouch, sorry. Been basing so many times that managed to miss this, thanks! > > variables internally and feedback_no_crashinfo will be introduced > > in next paches, thus after this patch the crash report is disabled. > > 4. paches -> patches. You need to turn on a spell checker or something. true, thanks! > > + > > +static struct errstat glob_errstat; > > +static bool cfg_send_crash = false; > > 5. Why do you have a global object for this module, and yet > this part of it is separated into another global variable? Good point. Actually I introduced this cfg_send_crash a way later than glob_errstat. Indeed we can keep this settings inside errstat. Also let me explain why this structure called errstat - it keeps not just report to send but also registers (we use it to print to a console), backtrace, report. And we're planning to gather diag_set() calls here as well and provide some box.info interface for last say 10 errors. On the other hands crash.c may be sounds better, dunno. > > +static unsigned char * > > +base64_encode(unsigned char *dst, unsigned char *src, size_t src_len) > > +{ > > 6. Why can't you use the existing base64_encode() function from > base64.h? It is not different from your version. You both use global > variables (static also is global, just not visible everywhere). So > your version is not 'safer' in terms of being called from a signal > handler. This library is not linked into src/lib/core by default I can add it actually but since it is third_party library I can't be sure that it won't be changed someday leading to unpredicted results. As you might note I try to use local functions as much as I can and I think we need to implement own strlen/snprintf and etc here as well because when we're inside sigsegv some state of libc/third_party components might be broken. If you think it is safe to reuse base64 here I'll link this library in. > > + > > +#define strlcpy_a(dst, src) strlcpy(dst, src, sizeof(dst)) > > 7. What is _a? array, we use sizeof(dst) > > + > > +struct errstat * > > +errstat_get(void) > > 8. Why do you ever need to get it? Why the stat is not entirely > in the .c file? It heavily depends on the platform, so it does > not make much sense to expose it to any external code. It won't > be able to use it properly except for some common things. True. Leftover from previous design. Thanks! > > + > > +static inline > > +uint64_t timespec_to_ns(struct timespec *ts) > > 9. Please, put return type on a separate line. On the same line > as 'static inline'. yeah, sorry for this typo. > > + localtime_r(&sec, &tm); > > + ssize_t total = strftime(start, len, "%F %T %Z", &tm); > > + start += total; > > + if (total < len) > > + return buf; > > + buf[len-1] = '\0'; > > 10. Lets conform with our code style and use spaces before and after > binary operators. OK > > + } else > > + pr_err("can't fetch uname"); > > 11. Lets conform with the code style, and use {} either in both 'if' > and 'else', or in none. Yeah, sorry, thanks! > > +void > > +cfg_errstat_set_params(void) > > 12. I suggest you to rename it to errstat_cfg(). > > 'cfg' is a prefix used by 'cfg' module, which you also > use here. This is probably why we have box_cfg, raft_cfg_*, > iproto_cfg_* and so on. sure > > +{ > > + struct errstat_crash *cinfo = &errstat_get()->crash_info; > > + const char *host = cfg_gets("feedback_host"); > > + int enabled = cfg_getb("feedback_enabled"); > > 13. For flags we use name prefix 'is_'. Please, blend in. nod > > + int no_crashinfo = cfg_getb("feedback_no_crashinfo"); > > 14. That is another proof that the module name is misleading - you > even use crashinfo in the options. Does not it look consistent > to name the module 'crashinfo' too? (Or something else with 'crash' > and without 'stat' in name.) You know I think I agree. It is not clear when error statistics gonna be implemented, so crashinfo looks pretty fine. Will rename. > > + > > +void > > +errstat_reset(void) > > 15. This function is never used. thanks! will drop. > > +static void > > +prepare_report_script(void) > > +{ > > + struct errstat_crash *cinfo = &errstat_get()->crash_info; > > + struct errstat_build *binfo = &errstat_get()->build_info; > > + struct errstat_uname *uinfo = &errstat_get()->uname_info; > > + > > + char *p, *e; > > + > > +#ifdef ENABLE_BACKTRACE > > + /* > > + * We can't use arbitrary data which can be misinterpreted > > + * by Lua script when we pass it to a script. > > + * > > + * WARNING: We use report_encoded as a temp buffer. > > 16. Static buffer is much bigger, and is already there. Why > can't you use it? Instead you somewhy add several kilobytes of > another static buffer padding out the process size. static buffer is three pages only while we might need more size i suspect. let me reconsider this moment maybe indeed using tt_static would suite better. thanks! > > + > > + snprintf_safe("require(\'http.client\').post(\'%s\'," > > + "'{\"crashdump\":{\"version\":\"%d\"," > > + "\"data\":\"%s\"}}',{timeout=1}); os.exit(1);", > > 17. Why so small timeout? this is the same timeout the feedback daemon uses. I can increase it or make it configurable if you prefer. > > +out: > > + pr_crit("unable to prepare a crash report"); > > + struct sigaction sa = { > > + .sa_handler = SIG_DFL, > > + }; > > + sigemptyset(&sa.sa_mask); > > + sigaction(SIGABRT, &sa, NULL); > > 18. Why do you touch the signal handler here? You didn't > change it anywhere in this file. It is taken from main signal handler code. I thought it was done this way in presume that this is safer -- ie even if one day code get changed and someone add sigabrt hander we still will produce a coredump. Probably worth to just drop out. > > + abort(); > > +} > > + > > +void > > +errstat_exec_send_crash(void) > > 19. Why is it called 'exec'? Because it runs exec inside. I can drop this exec_ if you prefer. > > + > > +#if defined(__cplusplus) > > +extern "C" { > > +#endif /* defined(__cplusplus) */ > > + > > +#define ERRSTAT_REPORT_VERSION 1 > > 20. It is not used out of .c file. I suggest you to > move it there. ok > > + > > +/** > > + * Return a pointer to the info keeper. > > + */ > > +extern struct errstat * > > 21. Please, omit 'extern'. They don't make any difference > here, and stand out of all the other libs we have. ok > > + > > +/** > > + * Collect a crash. > > + */ > > +extern void > > +errstat_collect_crash(int signo, siginfo_t *siginfo, void *context); > > + > > +/** > > + * Send a crash report. > > + */ > > +extern void > > +errstat_exec_send_crash(void); > > 22. Why do you have collect and send separated? Why can't it just be > something like 'crashinfo_handle_crash(sig stuff...);' To reuse regs and backtrace
next prev parent reply other threads:[~2020-12-05 19:58 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-04 15:29 [Tarantool-patches] [PATCH v3 0/4] crash dump: implement sending feedback Cyrill Gorcunov 2020-12-04 15:30 ` [Tarantool-patches] [PATCH v3 1/4] backtrace: allow to specify destination buffer Cyrill Gorcunov 2020-12-05 18:30 ` Vladislav Shpilevoy 2020-12-05 18:52 ` Cyrill Gorcunov 2020-12-04 15:30 ` [Tarantool-patches] [PATCH v3 2/4] errstat: add crash report base code Cyrill Gorcunov 2020-12-05 18:33 ` Vladislav Shpilevoy 2020-12-05 19:58 ` Cyrill Gorcunov [this message] 2020-12-06 15:50 ` Vladislav Shpilevoy 2020-12-04 15:30 ` [Tarantool-patches] [PATCH v3 3/4] crash: use errstat code in fatal signals Cyrill Gorcunov 2020-12-05 18:33 ` Vladislav Shpilevoy 2020-12-05 20:04 ` Cyrill Gorcunov 2020-12-04 15:30 ` [Tarantool-patches] [PATCH v3 4/4] cfg: configure crash report sending Cyrill Gorcunov 2020-12-05 18:34 ` Vladislav Shpilevoy 2020-12-05 18:30 ` [Tarantool-patches] [PATCH v3 0/4] crash dump: implement sending feedback 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=20201205195827.GC2303@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 v3 2/4] errstat: add crash report base code' \ /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