From: Dave Jones <davej@codemonkey.org.uk>
To: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: makedumpfile: ELF format issues (RE: makedumpfile: Fix divide by zero in print_report())
Date: Wed, 9 Oct 2019 17:38:55 -0400 [thread overview]
Message-ID: <20191009213855.GA14574@codemonkey.org.uk> (raw)
In-Reply-To: <4AE2DC15AC0B8543882A74EA0D43DBEC03591761@BPXM09GP.gisp.nec.co.jp>
On Wed, Oct 09, 2019 at 08:03:51PM +0000, Kazuhito Hagio wrote:
> > 0x0000000000000000 0x0000000000000000 0
> > NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000
> > 0x0000000000000000 0x0000000000000000 0
> >
>
> In this case, was the "makedumpfile Completed." message emitted?
> It looks like the buffer of program headers was not written to the file..
Our logging infra didn't capture the makedumpfile output. I've fixed
that up, so hopefully next time..
> Anyway, a debugging patch attached below.
>
> > There are some other failure cases with non-null data, so maybe there's >1 bug here.
> > I've not seen an obvious pattern to this. eg...
> >
> > https://pastebin.com/2uM4sBCF
> >
>
> As for this case, I suspect that Elf64_Ehdr.e_phnum overflows
> (i.e. num_loads_dumpfile > 65535):
Oh, good catch. These are 256GB machines, so after discarding
everything, that explains why we end up with so many sections.
This also explains why it sometimes works I think, when the discarding
manages to get the total nr headers <64k.
> > I'll put your patch on some of the affected hosts and see if this
> > changes behaviour in any way.
>
> If you can try the patch below, which includes the previous patch,
> please show me:
> - the debugging output of makedumpfile
> - readelf -a vmcore
> - ls -ls vmcore
Will take me a few days (travelling right now), but when hopefully by
the time I get back we'll have some data.
thanks for looking into this.
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-10-09 21:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 20:03 makedumpfile: ELF format issues (RE: makedumpfile: Fix divide by zero in print_report()) Kazuhito Hagio
2019-10-09 21:38 ` Dave Jones [this message]
2019-10-28 15:18 ` Kazuhito Hagio
2019-11-07 16:12 ` Kazuhito Hagio
2019-11-13 19:36 ` Kazuhito Hagio
2019-11-22 20:37 ` Dave Jones
2019-10-16 15:29 ` Dave Jones
2019-10-17 20:55 ` Kazuhito Hagio
2019-10-18 4:36 ` Dave Jones
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=20191009213855.GA14574@codemonkey.org.uk \
--to=davej@codemonkey.org.uk \
--cc=k-hagio@ab.jp.nec.com \
--cc=kexec@lists.infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.