From: linux err <linux_err@yahoo.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: Core file size?
Date: Fri, 1 Dec 2006 07:46:02 -0800 (PST) [thread overview]
Message-ID: <149400.32583.qm@web56501.mail.re3.yahoo.com> (raw)
In-Reply-To: <17775.22303.407587.991319@cerise.gclements.plus.com>
This patch fixed it.
http://lkml.org/lkml/2005/6/13/204
The ELF core dump code has one use of off_t when
writing out segments. Some of the segments may be
passed the 2GB limit of an off_t, even on a 32-bit
system, so it's important to use loff_t instead. This
fixes a corrupted core dump in the bigcore test in
GDB's testsuite.
Signed-off-by: Daniel Jacobowitz
<dan@codesourcery.com>
Index: linux-2.6.11/fs/binfmt_elf.c
===================================================================
--- linux-2.6.11.orig/fs/binfmt_elf.c 2005-06-09
16:38:17.000000000 -0400
+++ linux-2.6.11/fs/binfmt_elf.c 2005-06-10
00:10:52.000000000 -0400
@@ -1125,7 +1125,7 @@ static int dump_write(struct
file *file,
return file->f_op->write(file, addr, nr,
&file->f_pos) == nr;
}
-static int dump_seek(struct file *file, off_t off)
+static int dump_seek(struct file *file, loff_t off)
{
if (file->f_op->llseek) {
if (file->f_op->llseek(file, off, 0) != off)
--- Glynn Clements <glynn@gclements.plus.com> wrote:
>
> linux err wrote:
>
> >
> > Does anyone know what determines the size of a
> core
> > dump? I have a process running out of memory (it
> > allocates about 3GB) - but the size of core varies
> > (between 2-3GB) depending on how much the process
> > wrote on the allocated memory.
> >
> > Also, the time it takes to write the core (same
> size)
> > varies??
> >
> > I briefly looked at elf_core_dump and
> get_user_pages()
> > in binfmt_elf.c. Is there any documentation on
> this?
> > Or anyone knows how it works?
>
> The relevant function seems to be maydump() (in
> binfmt_elf.c); this
> determines whether or not a given VM area should be
> dumped.
>
> Essentially, it doesn't dump data which can be
> obtained elsewhere,
> e.g. from an executable, shared library, unmodified
> mmap()d file, etc.
>
> Primarily, this prevents dumping the .text and
> .rodata segments of the
> executable and shared libraries, which will often
> account for most of
> a process' address space.
>
> --
> Glynn Clements <glynn@gclements.plus.com>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
next prev parent reply other threads:[~2006-12-01 15:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-30 14:13 Core file size? linux err
2006-11-30 22:11 ` Glynn Clements
2006-12-01 15:46 ` linux err [this message]
[not found] <456EF0C0.6030706@ladadee.com>
2006-11-30 15:29 ` linux err
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=149400.32583.qm@web56501.mail.re3.yahoo.com \
--to=linux_err@yahoo.com \
--cc=linux-c-programming@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).