Kawai, Hidehiro wrote:
Requirements are:
(1) a user can change the core dump settings _anytime_
- sometimes want to dump anonymous shared memory segments and
sometimes don't want to dump them
I might not have been sufficiently clear about this in my previous
e-mail. Currently,
Hi,
Markus Gutschke wrote:
> Kawai, Hidehiro wrote:
>
>> This patch series is version 3 of the core dump masking feature,
>> which provides a per-process flag not to dump anonymous shared
>> memory segments.
>
> I just wanted to remind you that you need to be careful about dumping
> the [vdso]
Hi,
Markus Gutschke wrote:
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no
Kawai, Hidehiro wrote:
Requirements are:
(1) a user can change the core dump settings _anytime_
- sometimes want to dump anonymous shared memory segments and
sometimes don't want to dump them
I might not have been sufficiently clear about this in my previous
e-mail. Currently,
Pavel Machek <[EMAIL PROTECTED]> wrote:
> By same argument, we should just give up the coredumping in kernel. It
> is rarely tested, so someone will just get it wrong.
Not so rare... Lots of people still use Evolution after all:-)
However, to counter your point, I'll point out that there's
> > While I am sure you could construct scenarios where this would happen,
> > realistically the only one I have run into were stack overflows, and they
> > can
> > be handled by carefully setting up an alternate stack for signal handlers --
> > just make sure the entire stack is already dirtied
Markus Gutschke <[EMAIL PROTECTED]> wrote:
> > How does it work when you can't actually get back to userspace to have
> > userspace do the coredump? You still have to handle the userspace
> > equivalents of double/triple faults.
>
> My experience shows that there are only very rare occurrences
Markus Gutschke [EMAIL PROTECTED] wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace
equivalents of double/triple faults.
My experience shows that there are only very rare occurrences of
While I am sure you could construct scenarios where this would happen,
realistically the only one I have run into were stack overflows, and they
can
be handled by carefully setting up an alternate stack for signal handlers --
just make sure the entire stack is already dirtied before
Pavel Machek [EMAIL PROTECTED] wrote:
By same argument, we should just give up the coredumping in kernel. It
is rarely tested, so someone will just get it wrong.
Not so rare... Lots of people still use Evolution after all:-)
However, to counter your point, I'll point out that there's just
David Howells wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace equivalents
of double/triple faults.
My experience shows that there are only very rare occurrences of
situations where you cannot get
> Kawai, Hidehiro wrote:
> >This patch series is version 3 of the core dump masking feature,
> >which provides a per-process flag not to dump anonymous shared
> >memory segments.
>
> I just wanted to remind you that you need to be careful about dumping
> the [vdso] segment no matter whether you
Markus Gutschke <[EMAIL PROTECTED]> wrote:
> As an alternative to your kernel patch, you could achieve the same goal in
> user space, by linking my coredumper
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace
Markus Gutschke [EMAIL PROTECTED] wrote:
As an alternative to your kernel patch, you could achieve the same goal in
user space, by linking my coredumper
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no matter whether you omit other
David Howells wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace equivalents
of double/triple faults.
My experience shows that there are only very rare occurrences of
situations where you cannot get
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no matter whether you omit other
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no matter whether you omit other
Hi,
David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>
>>To avoid the above situation we can limit the core file size by
>>setrlimit(2) or ulimit(1). But this method can lose important data
>>such as stack because core dumping is terminated halfway.
>>So I suggest keeping
Hi,
David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
To avoid the above situation we can limit the core file size by
setrlimit(2) or ulimit(1). But this method can lose important data
such as stack because core dumping is terminated halfway.
So I suggest keeping shared memory
Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> To avoid the above situation we can limit the core file size by
> setrlimit(2) or ulimit(1). But this method can lose important data
> such as stack because core dumping is terminated halfway.
> So I suggest keeping shared memory segments from being
Hi,
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In this version, /proc//coredump_omit_anonymous_shared file
is provided as an interface instead of the previous
/proc//core_flags. If you have
Hi,
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In this version, /proc/pid/coredump_omit_anonymous_shared file
is provided as an interface instead of the previous
/proc/pid/core_flags. If you
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
To avoid the above situation we can limit the core file size by
setrlimit(2) or ulimit(1). But this method can lose important data
such as stack because core dumping is terminated halfway.
So I suggest keeping shared memory segments from being dumped
24 matches
Mail list logo
