On Thu, 10 May 2001 12:40:42 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said:
The process and signal-related structures may be inconsistent if the
debugger disregards existing locks held over those structures. It does
not matter if code is currently still executing, it matters that
On Mon, 14 May 2001, Garrett Wollman wrote:
On Thu, 10 May 2001 12:40:42 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said:
The process and signal-related structures may be inconsistent if the
debugger disregards existing locks held over those structures. It does
not matter if code is
On 09-May-01 Dima Dorfman wrote:
[ -stable dropped from cc list ]
John Baldwin [EMAIL PROTECTED] writes:
On 09-May-01 Robert Watson wrote:
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the
On Wed, 9 May 2001, Garrett Wollman wrote:
On Tue, 8 May 2001 23:31:51 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said:
I followed everything here fine until you asserted that the debugger
shouldn't need any locks.
When the debugger is running, everything else should have been
On 10-May-01 Robert Watson wrote:
On Wed, 9 May 2001, Garrett Wollman wrote:
On Tue, 8 May 2001 23:31:51 -0400 (EDT), Robert Watson
[EMAIL PROTECTED] said:
I followed everything here fine until you asserted that the debugger
shouldn't need any locks.
When the debugger is running,
On 09-May-01 Robert Watson wrote:
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the struct proc (first pointer in the display) and
then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then
On Wed, 9 May 2001, John Baldwin wrote:
I am more worried about the fact that you can deadlock the debugger.
What does the debugger do if another process hold the proc lock on the
process you want to kill? Cute, eh? The debugger is an extra special
environment. Most of the time you've
On Tue, 8 May 2001 23:31:51 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said:
I followed everything here fine until you asserted that the debugger
shouldn't need any locks.
When the debugger is running, everything else should have been
forcibly halted.
-GAWollman
To Unsubscribe: send mail
[ -stable dropped from cc list ]
John Baldwin [EMAIL PROTECTED] writes:
On 09-May-01 Robert Watson wrote:
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the struct proc (first pointer in the
Dag-Erling Smorgrav wrote:
Plus, your program doesn't even do what you think it does (because a)
it has at least one significant bug and b) malloc() doesn't behave the
way you think it does). And even if it did, the /dev/random stuff is
pointless, you can achieve the same effect by setting
Jordan Hubbard wrote:
That's like saying that putting someone
into orbit is a simple matter of determining what escape velocity is
necessary from an object with earth's mass and deciding how many tons
of payload you want to insert at what altitude. The devil is, as they
say, all in the
Dennis Glatting wrote:
What is memory exhaustion?
Uh, when I perform a malloc() and get a NULL back? I
dunno, what do you call that?
Hitting an administratively enforced resource limitation.
Why would it kill random processes as opposed to the
offending process?
The offending process
Terry Lambert [EMAIL PROTECTED] writes:
So now the question becomes what is he testing that is
resulting in 4.3 locking up?.
Good question. It does some non-trivial stuff besides allocating:
buffered I/O and fork()/exec()'ing sync(1).
Your suggested replacement test might be fun to run, but
Terry Lambert [EMAIL PROTECTED] writes:
A number of operating systems will allow programs to be
parked precious. In AIX, this is done by establishing
a signal handler for the resource starvation condition;
programs without the handler just die. Programs with
the handler are permitted to
[ cc severely trimmed ]
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
I would *love* to have a DDB equivalent to 'kill -9', so I could drop
to the DDB prompt, check ps, kill a process or two, and drop back out
of DDB. It would have saved me a reboot and a longish fsck in this
case.
Mmm.. I
On Tue, 8 May 2001, John Baldwin wrote:
That's easy enough. Well, it used to be at least. You can use 'ps' to
find the address of the struct proc (first pointer in the display) and
then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then
hit 'c' to continue and voila, the
On Sun, 6 May 2001, Kris Kennaway wrote:
On Sat, May 05, 2001 at 02:37:07PM -0700, Dennis Glatting wrote:
I wrote a trivial program to fill vm and found I can reliably freeze my
system. It may not work on the first attempt, but certainly within three.
My command line is:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens, usually
interesting things. :) In this case, the application is well behaved (in
the error proccesing sense): it'll exit, thus releasing its memory
resources, when the kernel reports a
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens,
usually interesting things. :) In this case, the application is
well behaved (in the error proccesing sense): it'll exit, thus
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may or may not be memory (real or virtual)
available at that time.
Isn't memory exhaustion a
: The malloc() and calloc() functions return a pointer to
: the allocated memory if successful; otherwise a NULL
: pointer is returned and errno is set to ENOMEM.
:
:I assert memory exhaustion is would return unsuccessful on the
:malloc() call, no?
malloc() returns NULL if
On Mon, 07 May 2001 09:55:44 MST, Matt Dillon wrote:
Theoretically the system is supposed to start killing large processes
when memory + swap gets full, but that code does not appear to be working
as well as it should at the moment.
I think that's all that Dennis was
Matt Dillon [EMAIL PROTECTED] writes:
This argument rears its head about once a year and usually turns into a
huge flame war.
Yes, I was going to mention that - search the archives for memory
overcommit and you'll find most of what I've already said in this
thread, and plenty I
On Mon, May 07, 2001 at 07:02:32PM +0200, Dag-Erling Smorgrav wrote:
Matt Dillon [EMAIL PROTECTED] writes:
This argument rears its head about once a year and usually turns into a
huge flame war.
Yes, I was going to mention that - search the archives for memory
overcommit and
:While that's a reasonable question when you're in a support role, I'd
:certainly like to hear whether FreeBSD freezes on memory exhaustion is
:something people should just live with or whether it's symptomatic of
:a bug that someone might one day want to fix but which folks should, for
:now,
Sheldon Hearn [EMAIL PROTECTED] writes:
I think DES was responding to that flame war, rather than to Dennis'
actual question.
Actually, I was responding to Dennis' incorrect assumptions about
FreeBSD's VM system, as exhibited by his code (which reflects the way
he *thinks* the VM system
On Mon, 7 May 2001, Matt Dillon wrote:
their hands of the whole affair. A production machine with 128M of ram
and 1G of swap is going to go down the tubes performance-wise long
before it runs out of swap. Performance degredation under heavy
memory loads is a much more
:Indeed, this is an interesting area. In the process of
:researching how to best implement this for Linux I have
:found various reasons why both FreeBSD's and NetBSD's
:load control systems cannot work in various realistic
:scenarios.
It's not a load control system. It's an emergency
On Mon, 7 May 2001, Matt Dillon wrote:
:Indeed, this is an interesting area. In the process of
:researching how to best implement this for Linux I have
:found various reasons why both FreeBSD's and NetBSD's
:load control systems cannot work in various realistic
:scenarios.
A
load
:
: A
: load control system is something like... oh, the 20 second enforced swap
: out that can be triggered when the VM system is under extreme memory
: pressure.
:
:Yup. Too bad the 20 second enforced swap out isn't enforced...
:(at least, not by the code in vm_glue.c)
:
:I'll
On Mon, 7 May 2001, Alfred Perlstein wrote:
* Rik van Riel [EMAIL PROTECTED] [010507 10:59] wrote:
The next step is designing a load control system that
does work (not too hard) and having a reliable way of
detecting when exactly the system is thrashing (next
to impossible?).
You
On 7 May 2001, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may or may not be memory (real or virtual)
Okay, enough said.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Mon, 7 May 2001, Alfred Perlstein wrote:
In FreeBSD we submit a patch perhaps after having an N-way
conversation (*) about the problem being addressed.
I'm are awaiting your patch,
I'll let this contradiction speak for itself.
You'll see a detailed analysis soon, patches will come only
: For some reason banning you from the irc channel hasn't convinced
: you that complaining without providing patches isn't the way we do
: things around here.
:
:How about first analysing the problem in detail and
:trying to fix it after we understand the problem ?
:
:The current stage is that
You'll see a detailed analysis soon, patches will come only
after we've agreed on a way to fix the problem.
You've already had some folks respond to this, though I think the
argument has been mischaracterized as a BSD vs Linux thing. It's
not.
What people are (IMHO) really trying to argue
Dennis Glatting [EMAIL PROTECTED] writes:
On 7 May 2001, Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
On Monday 07 May 2001 08:10 am, Dag-Erling Smorgrav wrote:
malloc() will return NULL only if you hit a resource limit or exhaust
address space. There may
Dag-Erling Smorgrav wrote:
Dennis Glatting [EMAIL PROTECTED] writes:
I am intentionally testing at the limits to see what happens, usually
interesting things. :) In this case, the application is well behaved (in
the error proccesing sense): it'll exit, thus releasing its memory
On Sat, May 05, 2001 at 02:37:07PM -0700, Dennis Glatting wrote:
I wrote a trivial program to fill vm and found I can reliably freeze my
system. It may not work on the first attempt, but certainly within three.
My command line is:
a.out;a.out;a.out;a.out;a.out
The goal of my
On Sun, 6 May 2001, Kris Kennaway wrote:
On Sat, May 05, 2001 at 02:37:07PM -0700, Dennis Glatting wrote:
I wrote a trivial program to fill vm and found I can reliably freeze my
system. It may not work on the first attempt, but certainly within three.
My command line is:
On Sun, 06 May 2001 04:47:24 MST, Kris Kennaway wrote:
What resource limits have you set?
While that's a reasonable question when you're in a support role, I'd
certainly like to hear whether FreeBSD freezes on memory exhaustion is
something people should just live with or whether it's
On Sun, 6 May 2001, Sheldon Hearn wrote:
On Sun, 06 May 2001 04:47:24 MST, Kris Kennaway wrote:
What resource limits have you set?
While that's a reasonable question when you're in a support role, I'd
certainly like to hear whether FreeBSD freezes on memory exhaustion is
something
42 matches
Mail list logo
