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 Mon, Apr 22, 2013 at 8:32 AM, John Baldwin j...@freebsd.org 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
On Monday, April 22, 2013 12:29:29 pm Freddie Cash wrote:
On Mon, Apr 22, 2013 at 8:32 AM, John Baldwin j...@freebsd.org 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
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
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
/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 interface
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 mentioned ? There is
sysctl
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 behave in the similar way,
using writes and not private kernel interface.
Also, what /proc issues did you mentioned
?
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
prevented.
I believe that other usermode tracers also behave in the similar way
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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
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 bri...@mu.org 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
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
prevented.
I believe that other
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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 utrace(2
On 12/23/12 9:28 AM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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
On 21 December 2012 22:37, Alfred Perlstein bri...@mu.org 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
On 12/22/12 8:56 AM, Ed Maste wrote:
On 21 December 2012 22:37, Alfred Perlstein bri...@mu.org 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
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
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
- Original Message -
From: Benjamin Kaduk ka...@mit.edu
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:
- Original Message
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 well as on some bigeer ones
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 bytes, 32... to
4096 bytes
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 Thu, Mar 22, 2012 at 10:42 AM, Eric Saint-Etienne
eric.saintetie...@gmail.com 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
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 of
Here is some code which fails with malloc 1 page
and sometimes succeeds with large mallocs ( 16 pages)
What's wrong?
#include sys/param.h
#include sys/proc.h
#include sys/conf.h
#include sys/module.h
#include sys/sysent.h
#include sys/kernel.h
#include sys/systm.h
#include sys/sysproto.h
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() which uses
- Original Message -
From: RW rwmailli...@googlemail.com
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
-S
On Tue, 20 Mar 2012, rank1see...@gmail.com wrote:
- Original Message -
From: RW rwmailli...@googlemail.com
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
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 -s 32768
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
'-s' flag in order to use
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 HEAD. Under 8.1
MALLOC_OPTIONS=g will disable the thread-specific
). 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 programs?
OpenSolaris and Mac OS X. I didn't really
(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
problem is specific to FreeBSD (as evidenced by your post to a
FreeBSD-specific list) or is related
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
On Sun, Mar 6, 2011 at 10:34 AM, Ryan Stone ryst...@gmail.com 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
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 HEAD. Under 8.1
MALLOC_OPTIONS=g will disable
,
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 problem
is specific to FreeBSD (as evidenced
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 them. I have
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
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 malloc/free) badly. I am using
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
malloc/free) badly.
as opposed
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
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 case
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 anyone else
has ever
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. Maybe some kernel
hacker
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.
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 (blocks holding the same size
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
FreeBSD-7.x?
If so, should the man page
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.freebsd.org/mailman
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 malloc from within a signal
[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
-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
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
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:
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
___
freebsd-hackers
(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 support
;
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 if bzip2
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 loader uses malloc()/free
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
[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
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
demonstrates this?
-Garrett
[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 small, something like 14
KB) Mac
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 malloc use
the slab cache
() 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 the kernel malloc use
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-vs
* 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.
Initial results brought up
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 Googling
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
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 system
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) provided
was 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
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 system at the moment, so
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) provided by FreeBSD 6.1.
Then, time the running of the binary (on Athlon XP 2500+):
#/usr/bin
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) provided by FreeBSD 6.1
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
defined
在 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 ./fdtd.FreeBSD
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;
// but whatever it returns MUST
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;
// but whatever it returns MUST
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 to
the usage of malloc(0). It's
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 ) ? NULL : malloc( size
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 that
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 same. No?
There is no way to see a 0x800 return from malloc(0) as error.
So noone
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 next revision
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 having it done:
if (foo == (foo
On Wed, Jun 28, 2006 at 10:40:45PM -0700, Randall Hyde wrote:
Without seeing the code or the actual error message, I'm
guessing the answer is 42. Perhaps, some detail might
be appropriate.
I seriously doubt seeing the code will do much good.
Here's the offending line:
On Wed, 2006-Jun-28 22:40:45 -0700, Randall Hyde wrote:
I seriously doubt seeing the code will do much good.
Here's the offending line:
YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]),
yy_n_chars, num_to_read );
How about feeding the C source through the preprocessor, stripping out
Randall Hyde [EMAIL PROTECTED]
BTW, if anyone is intrested in the full FLEX source, it's part of the HLA
(High Level Assembler) source package found here:
http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip
Just wondering if those guys knew that IBM calls their mainframe
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 actually be used (as a pointer to the so-called minimal
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
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 :-).
They should check the return value of malloc
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)) == foo)
/* make noise
On Thu, 29 Jun 2006, Johannes Weiner wrote:
JWOn 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
JWBut this would be appropriate for catching
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
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.
But this would be appropriate for catching the error
On Thu, 29 Jun 2006, Matthias Andree wrote:
MAJohannes 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 was. It was 0x800, which doesn't count as failure.
MA
MA
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
behavior is as if the size were some nonzero
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
' (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
either as you did or that unique meant it would a value unique to
the usage of malloc(0). It's been clarified recently
-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 preprocessor
-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]
BTW, if anyone is intrested in the full FLEX source, it's
1 - 100 of 248 matches
Mail list logo
