On Monday, April 22, 2013 12:29:29 pm Freddie Cash wrote:
> On Mon, Apr 22, 2013 at 8:32 AM, John Baldwin wrote:
>
> > On Saturday, April 20, 2013 6:43:26 pm Robert Waksmundzki wrote:
> > > On NUMA systems allocated memory is striped across local and non-local
> > banks
> > in order to have consi
On Mon, Apr 22, 2013 at 8:32 AM, John Baldwin wrote:
> On Saturday, April 20, 2013 6:43:26 pm Robert Waksmundzki wrote:
> > On NUMA systems allocated memory is striped across local and non-local
> banks
> in order to have consistent performance in case the task is rescheduled to
> a
> different C
On Saturday, April 20, 2013 6:43:26 pm Robert Waksmundzki wrote:
> On NUMA systems allocated memory is striped across local and non-local banks
in order to have consistent performance in case the task is rescheduled to a
different CPU socket.
> When a process is pinned to a single CPU socket with
On 2013/04/21 06:43, Robert Waksmundzki wrote:
On NUMA systems allocated memory is striped across local and non-local banks in
order to have consistent performance in case the task is rescheduled to a
different CPU socket.
When a process is pinned to a single CPU socket with cpuset having the m
On NUMA systems allocated memory is striped across local and non-local banks in
order to have consistent performance in case the task is rescheduled to a
different CPU socket.
When a process is pinned to a single CPU socket with cpuset having the memory
allocator prefer local banks would probabl
ein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
> >>>>
> >>> Why do you need to expedite the records through the ktrace at all ?
> >>> Wouldn't direct write(2)s to a file allow for better performance
> >>> due to not str
o not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system interface would be
prevented.
I believe that other usermode tracers also behave in the similar way,
using writes and not private kernel interface.
Also, what /proc issues did you ment
direct write(2)s to a file allow for better performance
> > due to not stressing kernel memory allocator and single writing thread ?
> > Also, the malloc coupling to the single-system interface would be
> > prevented.
> >
> > I believe that other usermode tracers also beh
/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
Why do you need to expedite the records through the ktrace at all ?
Wouldn't direct write(2)s to a file allow for better performance
due to not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system inte
b68~1...utrace2
>
Why do you need to expedite the records through the ktrace at all ?
Wouldn't direct write(2)s to a file allow for better performance
due to not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system interface would be
pre
On 1/10/13 1:41 AM, Alfred Perlstein wrote:
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to
take a look at malloc+utrace(2) and decided to make a tool to debug
where leaks are
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to take a look
at malloc+utrace(2) and decided to make a tool to debug where leaks are coming
from.
A few hours later I have:
1) a new
On 12/23/12 9:28 AM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
So the other day in an effort to debug a memory leak I decided to take a look
at malloc+utrace(2) and decided to make a tool to debug where leaks are coming
from.
A few hours later I have:
1) a new
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
> So the other day in an effort to debug a memory leak I decided to take a look
> at malloc+utrace(2) and decided to make a tool to debug where leaks are
> coming from.
>
> A few hours later I have:
> 1) a new version of ut
On 12/22/12 8:56 AM, Ed Maste wrote:
On 21 December 2012 22:37, Alfred Perlstein wrote:
Is it time to start installing with some form of debug symbols? This would
help us also with dtrace.
I just posted a patch to add a knob to build and install standalone
debug files. My intent is that we w
On 21 December 2012 22:37, Alfred Perlstein wrote:
> Is it time to start installing with some form of debug symbols? This would
> help us also with dtrace.
I just posted a patch to add a knob to build and install standalone
debug files. My intent is that we will build releases with this
enabled
Hey guys.
So the other day in an effort to debug a memory leak I decided to take a
look at malloc+utrace(2) and decided to make a tool to debug where leaks
are coming from.
A few hours later I have:
1) a new version of utrace(2) (utrace2(2)) that uses structured data to
prevent overloading
- Original Message -
From: Benjamin Kaduk
To: rank1see...@gmail.com
Cc: hack...@freebsd.org
Date: Tue, 20 Mar 2012 23:42:44 -0400 (EDT)
Subject: Re: BUG: REL 9.0 - MD malloc of custom sector size
> On Tue, 20 Mar 2012, rank1see...@gmail.com wrote:
>
> > - Orig
On Thursday, March 22, 2012 3:57:11 pm Eric Saint-Etienne wrote:
> > If your kernel module creates a device in /dev that implements the
> > mmap method, then you don't need to worry about mucking around with
> > vm_maps and objects and whatnot. Your mmap method just needs to be
> > able to convert
Here is some code which fails with malloc < 1 page
and sometimes succeeds with large mallocs (> 16 pages)
What's wrong?
#include
#include
#include
#include
#include
#include
#include
#include
#include
// Copyright: skeleton took from an older post on the freebsd lis
> If your kernel module creates a device in /dev that implements the
> mmap method, then you don't need to worry about mucking around with
> vm_maps and objects and whatnot. Your mmap method just needs to be
> able to convert offsets into the device into physical memory
> addresses,
Yes I'm aware
On Thu, Mar 22, 2012 at 10:42 AM, Eric Saint-Etienne
wrote:
> Actually when using kernel_map, the object returned is NULL! However the
> the vm_entry_t it returns seems a valid address, its 'object' field is NULL
> too (that's consistent)
> That's the reason why I didn't find it in any existing 'p
> By using kernel_map instead of kmem_map, vm_map_lookup() now always
> return a vm_object. That's a big progress.
> As expected, when this object is kmem_object, the user mapping works
> fine (for smaller or larger mallocs.)
>
> Otherwise that object doesn't match kernel_object. It's an anonymous
On Wednesday, March 21, 2012 7:27:58 pm Eric Saint-Etienne wrote:
> Hi,
>
> >From within the freeBSD kernel, not all malloc are made equal:
> * malloc() smaller than KMEM_ZMAX (set to one page size) end up in
> UMA SLABs, themselves laid out in powers of 2 (from 16 byte
I've refined the behaviour I observe, which isn't consistent depending
on the size one mallocates.
(see interleaved comments)
> In my driver, I need to map some malloc-ed memory, obtained from
> another module, into userspace.
>
> The problem: on the smaller mallocs, as
Hi,
>From within the freeBSD kernel, not all malloc are made equal:
* malloc() smaller than KMEM_ZMAX (set to one page size) end up in
UMA SLABs, themselves laid out in powers of 2 (from 16 bytes, 32... to
4096 bytes)
* bigger malloc() are done through uma_large_malloc() wh
On Tue, 20 Mar 2012, rank1see...@gmail.com wrote:
- Original Message -
From: RW
To: freebsd-hackers@freebsd.org
Date: Sun, 18 Mar 2012 13:41:56 +
Subject: Re: BUG: REL 9.0 - MD malloc of custom sector size
On Sun, 18 Mar 2012 14:01:39 +0100
rank1see...@gmail.com wrote:
man
- Original Message -
From: RW
To: freebsd-hackers@freebsd.org
Date: Sun, 18 Mar 2012 13:41:56 +
Subject: Re: BUG: REL 9.0 - MD malloc of custom sector size
> On Sun, 18 Mar 2012 14:01:39 +0100
> rank1see...@gmail.com wrote:
>
> > man mdconfig
> >
> &g
On Sun, 18 Mar 2012 14:01:39 +0100
rank1see...@gmail.com wrote:
> man mdconfig
>
> -S sectorsize to use for malloc backed device
>
>
> I want to create MD device, with sector size of 4 Kb.
>
> It is CRITICAL to NOT append ANY suffixes, when specifing size, via
man mdconfig
-S sectorsize to use for malloc backed device
I want to create MD device, with sector size of 4 Kb.
It is CRITICAL to NOT append ANY suffixes, when specifing size, via '-s' flag
in order to use sectors, to set it's size.
# mdconfig -a -t malloc -S 4096
On 06/03/2011 18:35, Ryan Stone wrote:
On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone wrote:
I would try playing with MALLOC_OPTIONS. I seriously doubt that there
is an actual leak in jemalloc, but from my own experiences with it I
suspect that there are certain multithreaded malloc/free
rote:
> >> Hi all,
> >>
> >> I have a moderately threaded userland program (all C) I am working on
> >> (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using
> >> standard malloc/free) badly.
> > as opposed to what? OpenBSD? Linux? Wi
certain multithreaded malloc/free sequences
>> that interact badly with with the per-thread caching that jemalloc
>> performs. The first thing I would try is setting MALLOC_OPTIONS=7h to
>> disable the caching.
>>
>
> Wait, sorry, apparently this is a new option in H
On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone wrote:
> I would try playing with MALLOC_OPTIONS. I seriously doubt that there
> is an actual leak in jemalloc, but from my own experiences with it I
> suspect that there are certain multithreaded malloc/free sequences
> that interact bad
I would try playing with MALLOC_OPTIONS. I seriously doubt that there
is an actual leak in jemalloc, but from my own experiences with it I
suspect that there are certain multithreaded malloc/free sequences
that interact badly with with the per-thread caching that jemalloc
performs. The first
gt;> >> I have a moderately threaded userland program (all C) I am working on
>> (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using
>> standard malloc/free) badly.
>> > as opposed to what? OpenBSD? Linux? Windows? why do you think your
>> proble
; (using pthreads, freebsd 8.1 64bit). It seems to leak memory (using
> standard malloc/free) badly.
> > as opposed to what? OpenBSD? Linux? Windows? why do you think your
> problem is specific to FreeBSD (as evidenced by your post to a
> FreeBSD-specific list) or is related to threaded
On Mar 5, 2011, at 10:44 AM, Deomid Ryabkov wrote:
> On 03/05/2011 04:02 AM, Eric Anderson wrote:
>> Hi all,
>>
>> I have a moderately threaded userland program (all C) I am working on (using
>> pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
On Mar 5, 2011, at 6:23 AM, Eygene Ryabinkin wrote:
> Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote:
>> I have a moderately threaded userland program (all C) I am working
>> on (using pthreads, freebsd 8.1 64bit). It seems to leak memory
>> (using standard mall
On 03/05/2011 04:02 AM, Eric Anderson wrote:
Hi all,
I have a moderately threaded userland program (all C) I am working on (using
pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
malloc/free) badly.
as opposed to what? OpenBSD? Linux? Windows? why do you think your
Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote:
> I have a moderately threaded userland program (all C) I am working
> on (using pthreads, freebsd 8.1 64bit). It seems to leak memory
> (using standard malloc/free) badly. I am using pcap to capture
> packets and process th
Hi all,
I have a moderately threaded userland program (all C) I am working on (using
pthreads, freebsd 8.1 64bit). It seems to leak memory (using standard
malloc/free) badly. I am using pcap to capture packets and process them. I
have a handful of libs statically linked in (pcap is one, the
On Wednesday, February 02, 2011 01:04:15 pm Andrew Duane wrote:
> We are still using the FreeBSD 6 malloc routines, and are rather suddenly
> having a large number of problems with one or two of our programs. Before
> I dig into the 100+ crash dumps I have, I thought I'd see if any
We are still using the FreeBSD 6 malloc routines, and are rather suddenly
having a large number of problems with one or two of our programs. Before I dig
into the 100+ crash dumps I have, I thought I'd see if anyone else has ever
encountered this.
The problems all seem to stem from some
On Mon, Mar 01, 2010 at 09:24:40PM -0600, Dan Nelson wrote:
> Hm. Even after some reading, I'm not sure how the slabs keep track of which
> elements are allocated or free. I expected to find a bitmap somewhere that
> malloc() sets and free() clears, but I don't see it.
nd store the requested size in the additional 4 bytes.
Actually FreeBSD's userland malloc hasn't ever had a 4-byte-per-element
overhead like this. All BSD mallocs have been block-based, where all
objects in a page are the same size. The original bsd malloc had power-of-2
size groupings (b
Hi,
I am looking at the code that allocates and frees kernel memory. I
understand that allocating kernel memory is quite different from
the user level mallocs. In case of user level mallocs, we allocate
requested size + 4 bytes and store the requested size in the
additional 4 bytes.
However,
On Fri, 19 Sep 2008, Stephen Montgomery-Smith wrote:
I notice that if you use "malloc" from within a signal handler on
FreeBSD-6.x, that you can potentially trigger a "recursive call" error.
But this seems to have changed in FreeBSD-7.x.
Is it now permissible to call &q
On Fri, Sep 19, 2008 at 08:52:13AM -0500, Stephen Montgomery-Smith wrote:
> Is it now permissible to call "malloc" from within a signal handler in
> FreeBSD-7.x?
No.
Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.fre
Stephen Montgomery-Smith wrote:
I notice that if you use "malloc" from within a signal handler on
FreeBSD-6.x, that you can potentially trigger a "recursive call" error.
But this seems to have changed in FreeBSD-7.x.
The malloc implementation is completely new in Free
I notice that if you use "malloc" from within a signal handler on
FreeBSD-6.x, that you can potentially trigger a "recursive call" error.
But this seems to have changed in FreeBSD-7.x.
Is it now permissible to call "malloc" from within a signal handler in
FreeBS
Andrew MacIntyre wrote:
However my reading of the updated man page suggests that the malloc
options string should be "Dm" or "m" to turn off mmap() and only use
sbrk() - could you clarify why "d"?
Whoops, I meant "m", not "d".
Jason
_
Jason Evans wrote:
Andrew MacIntyre wrote:
In investigating a Python 2.6rc1 regression test failure on FreeBSD
7.0/amd64, as far as I can tell, malloc() does not return NULL when
available memory (including swap) is exhausted - the process just gets
KILLed.
Using ulimit -v to set a virtual
Andrew MacIntyre wrote:
In investigating a Python 2.6rc1 regression test failure on FreeBSD
7.0/amd64, as far as I can tell, malloc() does not return NULL when
available memory (including swap) is exhausted - the process just gets
KILLed.
Using ulimit -v to set a virtual memory use limit below
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Andrew MacIntyre wrote:
[snip]
| In investigating a Python 2.6rc1 regression test failure on FreeBSD
| 7.0/amd64, as far as I can tell, malloc() does not return NULL when
| available memory (including swap) is exhausted - the process just gets
[If this is not an appropriate forum for this query, please suggest
a more appropriate one]
In investigating a Python 2.6rc1 regression test failure on FreeBSD
7.0/amd64, as far as I can tell, malloc() does not return NULL when
available memory (including swap) is exhausted - the process just
Jordan Gordeev wrote:
> At present the amd64 kernel is loaded just above the first megabyte
> of physical memory.
Yes, I know, and the standard i386 kernel is loaded at 4 MB,
and the PAE kernel is loaded at 2 MB. It doesn't matter
much, though.
> I have no idea if the load
= 0x30;
heap_bottom = PTOV(memtop_copyin);
#else
heap_top = (void *)bios_basemem;
heap_bottom = (void *)end;
#endif
setheap(heap_bottom, heap_top);
If I understand correctly, the boot loader will use only
low memory (i.e. below 0x10) for malloc by default.
Extended memory is only used i
tom = PTOV(memtop_copyin);
#else
heap_top = (void *)bios_basemem;
heap_bottom = (void *)end;
#endif
setheap(heap_bottom, heap_top);
If I understand correctly, the boot loader will use only
low memory (i.e. below 0x10) for malloc by default.
Extended memory is only used if bzip2 or firewire s
On Thu, Jun 14, 2007 at 06:04:27PM -0700, Matthew Dillon wrote:
> From this point of view it is much, much better to bzero() memory that
> is already mapped then it is to map/unmap new memory.
For kernel land, you are right. For userland, there's one big down-side
to always bzero/memset ne
much better to bzero() memory that
is already mapped then it is to map/unmap new memory. I recently
audited DragonFly and found an insane number of IPIs flying about due
to PAGE_SIZE'd kernel mallocs using the VM trick via kernel_map &
kmem_alloc(). They all went away when I made
that
is already mapped then it is to map/unmap new memory. I recently
audited DragonFly and found an insane number of IPIs flying about due
to PAGE_SIZE'd kernel mallocs using the VM trick via kernel_map &
kmem_alloc(). They all went away when I made the kernel mall
[EMAIL PROTECTED] wrote:
> Do you know if that's with malloc or calloc? What portion of the source
> demonstrates this?
No source, but here's a quote from
http://boredzo.org/blog/archives/2006-11-26/calloc-vs-malloc:
For large blocks (where "large" is surprisingly s
his thread
I've come to the information that it's similar to -CURRENT: small
allocations are carved from the local pool, big ones from prezeroed
pages (from kernel).
Do you know if that's with malloc or calloc? What portion of the source
dem
[EMAIL PROTECTED] wrote:
> Hmmm... I wonder what the Mach kernel in OSX does to allocate memory
> then. I'll have to take a look at OpenDarwin's source sometime and see
> what it does.
Following the link chain from the benchmark link posted in this thread
I've come to the information that it's si
On Wed, 13 Jun 2007, Ed Schouten wrote:
* Garrett Cooper <[EMAIL PROTECTED]> wrote:
Garrett Cooper wrote:
Title says it all -- is there a particular reason why malloc/bzero
should be used instead of calloc?
-Garrett
As someone just brought to my attention, I should do some Go
* Garrett Cooper <[EMAIL PROTECTED]> wrote:
> Garrett Cooper wrote:
> >Title says it all -- is there a particular reason why malloc/bzero
> > should be used instead of calloc?
> > -Garrett
> As someone just brought to my attention, I should do some Googling.
&g
Garrett Cooper wrote:
Title says it all -- is there a particular reason why malloc/bzero
should be used instead of calloc?
-Garrett
As someone just brought to my attention, I should do some Googling.
Initial results brought up this:
<http://boredzo.org/blog/archives/2006-11-26/calloc
Title says it all -- is there a particular reason why malloc/bzero
should be used instead of calloc?
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
in order to turn off the copious assertions, not
to mention the statistics gathering code.
Before you do that though, it would be useful to turn statistics reporting
on (add MALLOC_OPTIONS=P to your environment when running the test
program) and see what malloc says is going on.
[I am away f
off the
copious assertions, not to mention the statistics gathering code.
Before you do that though, it would be useful to turn statistics
reporting on (add MALLOC_OPTIONS=P to your environment when running the
test program) and see what malloc says is going on.
[I am away from my -current syst
astonished by the real repeatable performance difference on
AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the
2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC"
defined (in Makefile) to use malloc(3) p
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道：
> On -CURENT amd64 (Athlon64 3000+, 512k L2 cache):
>
> With jemalloc (without MY_MALLOS):
> ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
> ...
> 116.34 real 113.69 user 0.00 sys
>
> With MY_MALLOC:
> ~/fdtd> /usr/bin/time ./fd
repeatable performance difference on
AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC&quo
500+ (1.8GHz, 512KB L2 Cache).
>
> After hacking, I found that the problem is nested in malloc(3) of
> FreeBSD libc.
>
> Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
>
> You may try to compile the program WITHOUT the macro "MY_MALLOC"
> defi
nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC"
defined (in Makefile) to use malloc(3) provided by FreeBSD 6.1.
Then, time the running of the binary (on Athlon XP 2500
On Saturday 01 July 2006 04:35, Matthias Andree wrote:
> Pat Lashley <[EMAIL PROTECTED]> writes:
>
> > BUT, that said, the safest and most portable coding practice would be:
> >
> >// The C standard does not require malloc(0) to return NULL;
> >
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote:
> >I went wandering through the C Working Group archives for the heck of
> >it, and apparently a lot of people were confused over this, thinking
> >either as you did or that "unique" meant it would a value unique
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote:
> Pat Lashley <[EMAIL PROTECTED]> writes:
>
> > BUT, that said, the safest and most portable coding practice would be:
> >
> >// The C standard does not require malloc(0) to return NULL;
> &g
Pat Lashley <[EMAIL PROTECTED]> writes:
> BUT, that said, the safest and most portable coding practice would be:
>
>// The C standard does not require malloc(0) to return NULL;
>// but whatever it returns MUST NOT be dereferenced.
>ptr = ( size == 0 )
> No, sir. Operator precedence: assign first, and then compare, thus the
> comparison will always be true (else you'd be comparing to undefined
> values, which isn't any better). You might as well write:
>
> foo = malloc(0);
> /* make noise */
Ok, just for havi
I went wandering through the C Working Group archives for the heck of
it, and apparently a lot of people were confused over this, thinking
either as you did or that "unique" meant it would a value unique to
the usage of malloc(0). It's been clarified recently (and will be in
the n
be comparing to undefined
> > values, which isn't any better). You might as well write:
> >
> > foo = malloc(0);
> > /* make noise */
>
> Ok, just for having it done:
>
> if (foo == (foo = some_val))
>
> .. would be right to check if foo stayed the
On Thu, 2006-Jun-29 15:09:23 -0700, Randall Hyde wrote:
>>How about feeding the C source through the preprocessor, stripping out
>>the #line directives, compiling it and posting the exact gcc error and
>>source context.
>
>Okay, I'll try that when I get home. But I was kind of under the
>impression
Hi,
On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote:
> No, sir. Operator precedence: assign first, and then compare, thus the
> comparison will always be true (else you'd be comparing to undefined
> values, which isn't any better). You might as well write:
&
On Thu, 29 Jun 2006, Harti Brandt wrote:
> Operator precedence is just for parsing, not for evaluation. The
> compiler may well first evaluate the foo on the right side of the == (by
> fetching it) and then go an call malloc and assign foo.
Right, thanks for reminding me. I don't
-Original Message-
>From: Thomas David Rivers <[EMAIL PROTECTED]>
>Sent: Jun 29, 2006 3:17 AM
>To: freebsd-hackers@freebsd.org, [EMAIL PROTECTED]
>Subject: Re: FLEX, was Re: Return value of malloc(0)
>
>"Randall Hyde" <[EMAIL PROTECTED]>
>&g
-Original Message-
>
>How about feeding the C source through the preprocessor, stripping out
>the #line directives, compiling it and posting the exact gcc error and
>source context.
Okay, I'll try that when I get home. But I was kind of under the impression
that *GCC* runs the preproces
ought that it could either 1) Return
> NULL; or 2) Behave as though it returned a 'minimum allocation' (which
> cannot be legally de-referenced).
I went wandering through the C Working Group archives for the heck of
it, and apparently a lot of people were confused over this, thinking
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> No, our implementation is NOT legal. We always return the SAME value. To
> be legal, we should not return that value again unless it has been
> free()-ed.
It is legal due to brain damaged definition of implementation defined
behavio
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> >The C Standard says the following about malloc(0):
> >
> > If the size of the space requested is zero, the behavior is
> > implementation-defined: either a null pointer is returned, or the
> > behavi
On Thu, 29 Jun 2006, Matthias Andree wrote:
MA>Johannes Weiner <[EMAIL PROTECTED]> writes:
MA>
MA>> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
MA>>
MA>>> The value returned from malloc(0) must not be dereferenced whatever it
MA>>>
Johannes Weiner <[EMAIL PROTECTED]> writes:
> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
>
>> The value returned from malloc(0) must not be dereferenced whatever it
>> was. It was 0x800, which doesn't count as "failure".
>
> B
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> No, our implementation is NOT legal. We always return the SAME value. To
> be legal, we should not return that value again unless it has been
> free()-ed.
It is legal due to brain damaged definition of implementation defined
behavi
On Thu, 29 Jun 2006, Johannes Weiner wrote:
JW>On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
JW>
JW>> The value returned from malloc(0) must not be dereferenced whatever it
JW>> was. It was 0x800, which doesn't count as "failure".
JW>
On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
> The value returned from malloc(0) must not be dereferenced whatever it
> was. It was 0x800, which doesn't count as "failure".
But this would be appropriate for catching the error:
if ((foo = malloc(0)) ==
Johannes Weiner <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
>> "If you use malloc(0) and are crazy enough to access the 'allocated'
>> memory we give you a SIGSEV to show you how dumb you are :-
The C Standard says the following about malloc(0):
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
> Andre Albsmeier <[EMAIL PROTECTED]> writes:
>
> >
> > The manpage makes me think that when malloc is called with 0
> > as argument (and no V-flag had been set) the pointer it returns
> > can actu
1 - 100 of 260 matches
Mail list logo
