On Mon, Sep 16, 2019 at 07:47:24AM +0700, Robert Elz wrote:
> | There have been OSes in the past where memory not freed yet at process
> | exit is _not_ freed by the system, and there might be again,
>
> Please everyone, let's retain some perspective. Systems like those
> (Roy
On Sep 16, 3:02am, Kamil Rytarowski wrote:
} On 16.09.2019 02:47, Robert Elz wrote:
} > Expecting any unix program (even the simplest) to simply compile and run
} > in a non-kernel environment is pointless, they simply won't work.
}
} As a non-trivial no-kernel example, nethack on rump
On Sep 16, 7:47am, Robert Elz wrote:
}
} I used to program such things in the past (distant past) - one of the
} requirements of the particular system I was using was that processes
} were not allowed to run for "too long" before calling the system process
} switch function (no kernel running
On 16.09.2019 02:47, Robert Elz wrote:
> Expecting any unix program (even the simplest) to simply compile and run
> in a non-kernel environment is pointless, they simply won't work.
As a non-trivial no-kernel example, nethack on rump unikernel:
https://github.com/anttikantee/rumprun-nethack
On
Date:Sun, 15 Sep 2019 19:42:06 +
From:David Holland
Message-ID: <20190915194206.gb6...@netbsd.org>
| There have been OSes in the past where memory not freed yet at process
| exit is _not_ freed by the system, and there might be again,
Please everyone, let's
On 15/09/2019 21:02, Marc Balmer wrote:
Doesn‘t exit clear all resources on posix systems?
Don't assume that exit would ever be called.
Code used in some RTOS, such as RTEMS, everything runs as a thread and
thus cannot call exit.
In this case, at the natural programs exit, resources need to
Doesn‘t exit clear all resources on posix systems?
> Am 15.09.2019 um 21:42 schrieb David Holland :
>
>> On Fri, Sep 13, 2019 at 07:03:40PM +0700, Robert Elz wrote:
>> It isn't so much that I think we need to save the cost of doing
>> the free() (though for ps it turns out to be harder than
On Fri, Sep 13, 2019 at 07:03:40PM +0700, Robert Elz wrote:
> It isn't so much that I think we need to save the cost of doing
> the free() (though for ps it turns out to be harder than you'd expect
> to actually get it right) but whether it is worth anyone time and
> effort to actually work
From: Kamil Rytarowski
Subject: Re: Leak Sanitizer - how to suppress leaks,Re: Leak Sanitizer - how to
suppress leaks
Date: Sat, 14 Sep 2019 13:45:08 +0200
> On 13.09.2019 14:03, Robert Elz wrote:
>
>> | I think we need to specify the definition. Leak is a memory object
&g
Martin Husemann wrote:
> On Sat, Sep 14, 2019 at 01:45:08PM +0200, Kamil Rytarowski wrote:
> > Thanks! I will go for __NO_LEAKS ifdef.
>
> But it is not a good idea to clutter perfectly fine sources with such
> #ifdefs and unused/untested/likely broken code (even if it does not affect
> the
On 14.09.2019 13:54, Martin Husemann wrote:
> On Sat, Sep 14, 2019 at 01:45:08PM +0200, Kamil Rytarowski wrote:
>> OK, thank you. So to sum it up. Plugging resource leaks costs time and
>> human effort and this is what is not wanted by some people. For those
>> who find it useless are not forced
On Sat, Sep 14, 2019 at 01:45:08PM +0200, Kamil Rytarowski wrote:
> OK, thank you. So to sum it up. Plugging resource leaks costs time and
> human effort and this is what is not wanted by some people. For those
> who find it useless are not forced to do it, so can ignore it. For
> others it can be
On 13.09.2019 14:03, Robert Elz wrote:
> | I think we need to specify the definition. Leak is a memory object
> | without a pointer referencing it.
>
> I can accept that as a definition. But we also need to recognise that
> there are no leaks after the program has finished. And the
Warner Losh wrote in :
|On Thu, Sep 12, 2019, 7:24 PM Simon Burge <[1]sim...@netbsd.org[/1]> wrote:
|
| [1] mailto:sim...@netbsd.org
|
||Kamil Rytarowski wrote:
|
||> I will revert it, but I am looking for a more generic approach.
||>
||> How about adding ifdef __NO_LEAKS like:
||>
||>
Date:Fri, 13 Sep 2019 19:03:40 +0700
From:Robert Elz
Message-ID: <24855.1568376...@jinx.noi.kre.to>
| Even lint had that ability from is beginning (30 years ago).
40. I cannot subtract... (and s/is/its/ - I cannot type either!)
kre
Date:Fri, 13 Sep 2019 02:07:43 +0200
From:Kamil Rytarowski
Message-ID: <1ea33d0c-fb0f-ecdd-1706-b11841dc6...@gmx.com>
| Please note that in all arguments about leak sanitization, that it uses
| internally the same mechanism as garbage collectors. lsan and libgc
On Thu, Sep 12, 2019 at 08:21:38PM -0600, Warner Losh wrote:
> When multiple people are doing leak busting, maybe over years, they
> eliminate many false positives so you can focus on the real issues w/o a
> run time penalty. Especially something in the library that comes up
> often... otherwise
On Thu, Sep 12, 2019, 7:24 PM Simon Burge wrote:
> Kamil Rytarowski wrote:
>
> > I will revert it, but I am looking for a more generic approach.
> >
> > How about adding ifdef __NO_LEAKS like:
> >
> > #ifdef __NO_LEAKS
> > free(3)?
> > #endif
> >
> > And in lsan/asan/valgrind/etc checks use
On 13.09.2019 03:24, Simon Burge wrote:
> Kamil Rytarowski wrote:
>
>> I will revert it, but I am looking for a more generic approach.
>>
>> How about adding ifdef __NO_LEAKS like:
>>
>> #ifdef __NO_LEAKS
>> free(3)?
>> #endif
>>
>> And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS.
>
>
Kamil Rytarowski wrote:
> I will revert it, but I am looking for a more generic approach.
>
> How about adding ifdef __NO_LEAKS like:
>
> #ifdef __NO_LEAKS
> free(3)?
> #endif
>
> And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS.
Sorry if I'm missing something that has been already
On 12.09.2019 21:24, Robert Elz wrote:
> Date:Thu, 12 Sep 2019 15:12:25 +0200
> From:Kamil Rytarowski
> Message-ID: <2a6e1fb2-cedc-4a57-750b-45f101be9...@gmx.com>
>
>
> | This proposal is practically equivalent of disabling leak detection at
> | all and removes
Date:Thu, 12 Sep 2019 15:12:25 +0200
From:Kamil Rytarowski
Message-ID: <2a6e1fb2-cedc-4a57-750b-45f101be9...@gmx.com>
| This proposal is practically equivalent of disabling leak detection at
| all and removes the whole purpose.
No it isn't. Or rather, it
On 12.09.2019 10:09, Robert Elz wrote:
> The right change to make however is to teach the santitsers (all of them)
> that exiting (via exit() or a return from main()) frees everything,
This proposal is practically equivalent of disabling leak detection at
all and removes the whole purpose.
Leak
> On Sep 12, 2019, at 11:09 AM, Robert Elz wrote:
>
> To me it seems apparent that the sanatiser is detecting the local variable
> in main() go out of scope when main() returns, and so the value it contains
> (the pointer to the allocated memory) is lost, and so it is determined that
> there
Date:Thu, 12 Sep 2019 02:58:41 +0200
From:Kamil Rytarowski
Message-ID: <373b9331-5306-9797-b4bd-8f6c52683...@gmx.com>
| I have tested interactive sh(1) with LSan and it does not leak when
| used.
It doesn't matter what code (if any) you run, there is always
On 11.09.2019 23:33, Robert Elz wrote:
> Date:Wed, 11 Sep 2019 21:13:24 +0200
> From:Kamil Rytarowski
> Message-ID: <6c853bc7-6510-459e-d451-51f988617...@gmx.com>
>
> | We have got even fixups in libc for such "nonsense" cases.
>
> Why? In 99% (or more) of libc
26 matches
Mail list logo
