The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Niemayer <niemayer.viag@isg.de>
To: linux-kernel@vger.kernel.org
Subject: unused shared memory is written into core dump - bug or feature?
Date: Tue, 12 Jun 2001 16:04:08 +0200	[thread overview]
Message-ID: <3B262158.29EFC01A@isg.de> (raw)

Hi everybody,

I just noticed that when I attach some SYSV shared memory segments
to my process and then that process dies from a SIGSEGV that _all_
the shared memory is dumped into the core file, even if it was never
used and therefore didn't show up in any of the memory statistics.

One may say: "Oh, that's just a feature". But for some reason, this
is a small catastrophy:

I try to share some memory between the child processes of an application.
At the time when the child processes are fork()ed, it is not known how
much shared memory will be needed later. No other processes should see
that memory.

I searched through the literature how this could be done, but alas,
the recommended methods such as mmap()ing "/dev/zero" with MAP_SHARED
or using MAP_ANON are not implemented in Linux as they are within
other Unices, and so using "ftruncate" to expand the shared memory
region doesn't work either.

So the only work-around I found was to attach the very maximum of
what is to be used as shared memory using the SYSV shared memory
functions, and allocating/using subsets of this memory later on
the "logical" level.

This of course means that any "parent" process starts by attaching
~512MB of shared memory, but since they are not mapped at that time,
there's no undue performance or memory/swap consumption.

But if one of the programs crashes (and you know, this is nothing
you can be sure to never happen :-), it stymies the whole system,
as the kernel first seems to map all the 512MB, then dumps them
into the core file.

Please tell me there is either a way to keep the kernel from dumping
these unused pages (but generate the much appreciated core-dump anyway)
or there is some better method to share memory with one's child processes
(not with the whole universe)  in a way that allows either the child or
the parent to extend the amount of shared memory... 

Thanks for any hints in advance,

Peter Niemayer

PS: Please CC me if you reply - thanks!

             reply	other threads:[~2001-06-12 14:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-12 14:04 Peter Niemayer [this message]
2001-06-12 14:56 ` unused shared memory is written into core dump - bug or feature? Christoph Rohland
2001-06-12 16:01 ` Alan Cox

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=3B262158.29EFC01A@isg.de \
    --to=niemayer.viag@isg.de \
    --cc=linux-kernel@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