dt71 at gmx.com writes:
...
It appears that it's not possible to make a proper API with
malloc_usable_size() included, at least when
multi-threading is involved (ie., in the modern world).
However, it is still useful to create an API that supports the following
cases:
...
Well, this
On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote:
On 27 Nov, Konstantin Belousov wrote:
On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote:
On 27 Nov, Konstantin Belousov wrote:
On Wed, Nov 27, 2013
On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote:
On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
Peter, could you, please, try to reproduce the issue ? It does not look
like a random hardware failure, since in all cases, it is curthread access
which is
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel compilation. See the patch at the end of message for exact change
proposed.
What does it do. It disallows useless and counter-intuitive behaviour of
the compiler(s) for the signed overflow. Basically, the issue is
On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote:
On Nov 29, 2013, at 3:44 PM, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
There is a difference between applications peeking into
implementation details that should be hidden, and
On 30 Nov, Konstantin Belousov wrote:
On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote:
On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
Peter, could you, please, try to reproduce the issue ? It does not look
like a random hardware failure, since in all cases,
+1, this caught us out with sendfile testing very recently :(
-a
On 30 November 2013 05:56, Konstantin Belousov kostik...@gmail.com wrote:
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel compilation. See the patch at the end of message for exact change
Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +:
The problem with using int or u_int for 1 or 2 byte values is that while
printing these 1 or 2 byte values I observed that sysctl module is
considering 4 bytes. Hence I see an undesired output. It is actually
dt71 at gmx.com writes:
...
So new flags could be [1]:
- realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving
it, to size s. With this restriction, when requesting more memory, and
the specified amount isn't available, don't do anything (when requesting
less memory,
In message caj-vmomc6cmuo__etm7x6w8hpg8mafl2stepdsz4jn0xn6m...@mail.gmail.com
, Adrian Chadd writes:
The compiler authors take the undefined part there as a blanket to perform
optimizations which are assuming that signed overflow cannot happen.
That's sufficient explanation for me to support
On 11/11/13 14:57, Teske, Devin wrote:
On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote:
On 11/11/13 14:30, Nathan Whitehorn wrote:
On 11/11/13 14:18, Teske, Devin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote:
Hello all,
On 30 Nov 2013, at 14:56, Konstantin Belousov kostik...@gmail.com wrote:
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel compilation. See the patch at the end of message for exact change
proposed.
What does it do. It disallows useless and counter-intuitive
On 30 November 2013 15:25, Dimitry Andric d...@freebsd.org wrote:
On 30 Nov 2013, at 14:56, Konstantin Belousov kostik...@gmail.com wrote:
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel compilation. See the patch at the end of message for exact change
Luigi Rizzo wrote this message on Fri, Nov 29, 2013 at 17:11 -0800:
On Fri, Nov 29, 2013 at 4:49 PM, Adrian Chadd adr...@freebsd.org wrote:
The reason I wouldn't implement this is to avoid having code that
_relies_ on this behaviour in order to function or perform well.
nobody ever
Adrian Chadd wrote, On 12/01/2013 01:33:
Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?
Well, there's -ftrapv.
___
freebsd-current@freebsd.org mailing list
John-Mark Gurney wrote, On 12/01/2013 03:20:
Either it happens rarely, and always doing a realloc won't hurt
performance, or it happens often, and then you should be using a larger
buffer in the first place..
What if a size-elastic implementation of a dynamic data structure would be able
to
Just came across this error...
zfs -mm master errors with
Assertion failed: (tq-tq_freelist != NULL), file
/master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c,
line 289.
Abort (core dumped)
___
On Sat, Nov 30, 2013 at 10:51:56PM -0500, Outback Dingo wrote:
Just came across this error...
zfs -mm master errors with
Assertion failed: (tq-tq_freelist != NULL), file
/master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c,
line 289.
Abort (core
you have to upgrade your pool to enable histogram i believe
zdb -mm master
Metaslabs:
vdev 0
metaslabs 103 offsetspacemap free
--- --- ---
-
metaslab 0 offset
On Sat, Nov 30, 2013 at 11:09:26PM -0500, Outback Dingo wrote:
you have to upgrade your pool to enable histogram i believe
zdb -mm master
So, is the problem with zfs(8), or zdb(8) ?
On Sat, Nov 30, 2013 at 11:04 PM, Glen Barber g...@freebsd.org wrote:
On Sat, Nov 30, 2013 at
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd adr...@freebsd.org wrote:
[..]
Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?
It wasn't all that long ago that we had this wonderful thing called
-Werror and had a clean
On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm pe...@wemm.org wrote:
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd adr...@freebsd.org wrote:
[..]
Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?
It wasn't all that long
On Sat, Nov 30, 2013 at 8:38 PM, Eitan Adler li...@eitanadler.com wrote:
On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm pe...@wemm.org wrote:
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd adr...@freebsd.org wrote:
[..]
Are you able to have clang/llvm/gcc tell us where/when code is relying
on
On Sat, Nov 30, 2013 at 04:33:17PM -0800, Adrian Chadd wrote:
On 30 November 2013 15:25, Dimitry Andric d...@freebsd.org wrote:
On 30 Nov 2013, at 14:56, Konstantin Belousov kostik...@gmail.com wrote:
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel
24 matches
Mail list logo
