On Mon, 14 May 2001, Garrett Wollman wrote:
> < 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
> > preemption can occ
< 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
> preemption can occur. The choices appear to be:
Preemption should never o
On 10-May-01 Robert Watson wrote:
>
> On Wed, 9 May 2001, Garrett Wollman wrote:
>
>> <> <[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 Wed, 9 May 2001, Garrett Wollman wrote:
> < 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.
The process and signal-related structures may be
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
>> >> f
[ -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 point
< 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 to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body o
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 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.
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 08-May-01 Dag-Erling Smorgrav wrote:
> 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).
>
[ 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.
Mm
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 permi
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 ru
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 pr
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
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 settin
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
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
> 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
:> 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
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 on
Okay, enough said.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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?).
:>
:> 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'
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
>
: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 measure
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 in
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 wor
: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,
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
> overcommi
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 ha
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 question
: 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 t
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 exhaust
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 ex
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
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, 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
> someth
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 sy
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 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 goa
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 program is simply to see how the system behaves under
memory exhaustion
44 matches
Mail list logo
