From: "Rob Mueller" <robm@fastmail.fm>
To: "Michael Kerrisk" <mtk.manpages@googlemail.com>,
"Bron Gondwana" <brong@fastmail.fm>
Cc: "Philippe De Muyter" <phdm@macqel.be>, <linux-kernel@vger.kernel.org>
Subject: Re: mmap'ed memory in core files ?
Date: Wed, 2 Jul 2008 16:35:22 +1000 [thread overview]
Message-ID: <3f2201c8dc0d$d1012d60$0b01a8c0@robmhp> (raw)
In-Reply-To: cfd18e0f0807012214o78353faal84a5fa764d3210bf@mail.gmail.com
>> This is particularly interesting on a 64 bit kernel where a bug in
>> your code causes you to try to read something about 2Gb into your
>> alleged mmaped file (actual size ~500 bytes) and the segfault causes
>> a coredump.
>
> Do you have a ssimple example program for this?
Trying to reproduce the problem, I think it's actually related to sparse
files.
$ cat a.c
#include <stdlib.h>
int main() {
unsigned int i;
char * a = malloc(3000000000u);
*(int *)0 = 0;
}
$ gcc a.c
$ ulimit -c 10240 && ./a.out
$ ls -l
-rw------- 1 root root 3000082432 Jul 2 02:23 core.7761
$
It's clearly sparse, but slightly unintuitive that the ulimit doesn't
actually limit the filesize, just the size of the data written to the file.
If I change the code to include this line after the malloc():
for (i = 0; i < 3000000000u; i++) a[i] = i % 256;
I get:
-rw------- 1 root root 10485760 Jul 2 02:25 core.8992
More what you'd expect.
One interesting side effect of running a 64-bit kernel + 32-bit userland is
that previously bugs that might have previously caused malloc() to fail (eg
underflowing integer to a huge value), now succeed and allocate a huge chunk
of memory rather than failing and causing the program to bailout/crash on
dereference.
Rob
next prev parent reply other threads:[~2008-07-02 6:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 13:21 mmap'ed memory in core files ? Philippe De Muyter
2008-07-01 18:16 ` Michael Kerrisk
2008-07-01 21:44 ` Bron Gondwana
2008-07-02 5:14 ` Michael Kerrisk
2008-07-02 6:35 ` Rob Mueller [this message]
2008-07-02 11:07 ` Andi Kleen
2008-07-02 11:52 ` Bron Gondwana
2008-07-02 10:50 ` Philippe De Muyter
2008-07-02 10:58 ` Michael Kerrisk
2008-07-02 11:04 ` Philippe De Muyter
2008-07-02 12:24 ` Stefan Richter
2008-07-02 13:16 ` Philippe De Muyter
2008-07-03 3:51 ` Hidehiro Kawai
2008-07-03 9:22 ` Philippe De Muyter
2008-07-04 5:50 ` Hidehiro Kawai
2008-07-04 6:33 ` Stefan Richter
2008-07-04 11:25 ` Philippe De Muyter
2008-07-04 14:29 ` Hugh Dickins
2008-07-04 11:13 ` Philippe De Muyter
2008-07-03 9:37 ` Philippe De Muyter
2008-07-03 16:52 ` [PATCH] ieee1394 : dump mmapped video1394 buffers in core files Philippe De Muyter
2008-07-04 18:33 ` Stefan Richter
2008-07-04 20:49 ` Philippe De Muyter
2008-07-02 13:30 ` mmap'ed memory in core files ? Christoph Hellwig
2008-07-02 11:01 ` Philippe De Muyter
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='3f2201c8dc0d$d1012d60$0b01a8c0@robmhp' \
--to=robm@fastmail.fm \
--cc=brong@fastmail.fm \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=phdm@macqel.be \
/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.