lkml.org 
[lkml]   [1999]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.2.14pre7
   Date: Sun, 21 Nov 1999 03:42:58 +0100 (CET)
From: Andrea Arcangeli <andrea@suse.de>

The 2.2.14pre5 behaviour is _very_ intentional.

It's the ptrace task that cause the fault and if something goes OOM then
it's _gdb_ and _not_ the innocent ptraced task that must be killed.

I disagree, the task being debugged has incurred a fault, on behalf of
gdb.

By your logic, we should adjust the RSS values of gdb during these
faults for the debugged task.

Also, if gdb dies, both tasks will most likely wind up getting killed.
In such a case, the user has no idea why it happened. However if you
kill the debugged task (who is the process consuming all the memory)
gdb still lives and the user can see that the subordinate task died
and ask the debugger why.

Actually, come to think of it, depending upon the signal disposition
of the debugged task at ptrace time, your kill selection could leave
gdb dead and the debugged task stuck in SIGSTOP state consuming all
of the memory it did before you killed gdb. Does this make any sense,
really?

Your argument states that if debugged task X consumes 2GB of ram, and
gdb taps in a page of X that puts the system into OOM state, gdb
should get killed and we should not kill X which is consuming 2GB of
ram.

Andreas, what are you smoking?

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.068 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site