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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox