Professional Web Applications Themes

malloc() / calloc() weirdness - UNIX Programming

Version: gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux) SuSE 8.2 Pro 2.4.20-4GB Dell PowerEdge 600SC 512MB Single Intel P4 2.4GHz malloc() is sporadically returning a valid (non-null) pointer, but the size of the allocation is 0 bytes. I've tried to work around this using calloc() to force an explicit initialization, and while it happens less frequently now it still happens. I've run all the code through valgrind 2.0.0, and have confirmed that there are no memory leaks. valgrind --trace-malloc=yes -v --leak-check=yes ./myprog Valgrind does pick up the 0-sized allocation when it happens, though: ==10733== Address 0x412896AC is 0 bytes after ...

  1. #1

    Default malloc() / calloc() weirdness

    Version: gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
    SuSE 8.2 Pro 2.4.20-4GB
    Dell PowerEdge 600SC 512MB Single Intel P4 2.4GHz

    malloc() is sporadically returning a valid (non-null) pointer, but
    the size of the allocation is 0 bytes. I've tried to work around
    this using calloc() to force an explicit initialization, and while it
    happens less frequently now it still happens.

    I've run all the code through valgrind 2.0.0, and have confirmed that
    there are no memory leaks.

    valgrind --trace-malloc=yes -v --leak-check=yes ./myprog

    Valgrind does pick up the 0-sized allocation when it happens, though:

    ==10733== Address 0x412896AC is 0 bytes after a block of size 128
    alloc'd
    ==10733== at 0x40028016: calloc (vg_replace_malloc.c:284)

    I've never seen this type of problem before, and I'm stumped.

    Rent Guest

  2. #2

    Default Re: malloc() / calloc() weirdness

    Rent This Space <invalid> writes:
     

    Huh?
     

    What exactly happens?
     

    You are probably crashing, and memory leaks have nothing to do with it.
     

    What was the entire valgrind message?
    You are probably corrupting heap, and not realizing that that's
    what you did.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.
    Paul Guest

  3. #3

    Default Re: malloc() / calloc() weirdness


    Rent This Space <invalid> writes:
     

    Sometimes code mallocs zero bytes.
    It can happen innocently enough:

    char ** list_to_array(listnode * list)
    {
    int n = list_count(list);
    char ** array = malloc(n * sizeof(char*));
    ...
    }

    So if you pass an emtpy list, n == 0 and it tries
    to malloc a zero-element array. As I recall, some
    mallocs honor such a request, and others return null.

    -SEan




    Sean Guest

  4. #4

    Default Re: malloc() / calloc() weirdness

    Rent This Space wrote: 

    This is called "lazy" allocation. The real allocation may when you
    perform your first write to part of the malloc'd block, and then it may
    be only the page containing the written data that is really allocated.
    Lazy allocation is a Linux kernel option (depending on the setting of
    /proc/sys/vm/overcommit_memory).

    Robert
    Robert Guest

  5. #5

    Default Re: malloc() / calloc() weirdness

    Robert Harris <co.uk> writes:
     [/ref]
     


    I doubt that; "lazy allocation" isn't visible in applications (unless
    you run out of memory, that is)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  6. #6

    Default Re: malloc() / calloc() weirdness

    Casper H.S. Dik wrote:
     [/ref]

    >
    >
    > I doubt that; "lazy allocation" isn't visible in applications (unless
    > you run out of memory, that is)[/ref]

    The OP wasn't seeing the result in his application (at least he wasn't
    saying so), but rather in valgrind, which might know more about what
    really goes on. His program has no way of finding the actual size of
    the allocated memory.

    Rolf Guest

  7. #7

    Default Re: malloc() / calloc() weirdness

    Rolf Magnus <de> writes:
     

    Unlikely; that would mean that valgrind cared whether a particular
    page of virtual memory actually had backing store allocated to it or
    not and before you run out of swap beause of overcomitting you can't
    even tell.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  8. #8

    Default Re: malloc() / calloc() weirdness

    [newsgroups trimmed; given the futility of posting to gnu.gcc.help]

    in comp.unix.programmer i read:
    [slightly rearranged] 
     [/ref]

    as it happens this is everything that doesn't matter. it's the standard c
    library that matters (which is not supplied by gcc), which we might infer
    from the version of your linux distribution, still it would be better to
    see it first hand than to guess. as it happens the problem is likely not
    in the library either, rather in the application's programmer(s).
     [/ref]

    nothing wrong with that. are you sure it sometimes returns a null pointer
    and other times returns a non-null pointer? it should do one or the other
    all the time -- which one is up to the library and must be doented.
     [/ref]

    sometimes a zero sized allocation is benign, but all too often other code
    does inappropriate things so valgrind warns about it.
     
     

    all malloc's had better `honor' such a request, the c standard demands it.
    the standard does not specify whether a null pointer is returned. but what
    is returned may not be dereferenced. programmers that think it should be a
    null pointer often do the wrong thing.

    c99 7.20.3#1 says `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 access an object.' similar wording
    exists in the previous version of the standard.
     

    often undefined behavior then happens because the following code is usually
    something like:

    if (0 != array)
    {
    int i;
    for (i=0; i<n; i++)
    {
    array[i] = ...
    ...
    }
    }
    return array;
    }

    which conflates the `is there a reason to allocate?' and `was allocation
    successful?' tests, typically because the programmer thinks that malloc(0)
    would/must return a null pointer. [the loop probably has the same issue.]

    it should be written more like:

    char ** list_to_array(listnode * list)
    {
    char ** array = 0;
    int n = list_count(list);
    if (0 < n)
    {
    array = malloc(n * sizeof *array);
    if (0 != array)
    {
    int i;
    for (i=0; i<n; i++)
    {
    array[i] = ...
    ...
    }
    }
    }
    return array;
    }

    --
    a signature
    those Guest

  9. #9

    Default Re: malloc() / calloc() weirdness

    In article <net>,
    those who know me have no need of my name <net>
    wrote:
     
    >
    > often undefined behavior then happens because the following code is usually
    > something like:
    >
    > if (0 != array)
    > {
    > int i;
    > for (i=0; i<n; i++)
    > {
    > array[i] = ...
    > ...
    > }
    > }
    > return array;
    > }
    >
    > which conflates the `is there a reason to allocate?' and `was allocation
    > successful?' tests, typically because the programmer thinks that malloc(0)
    > would/must return a null pointer. [the loop probably has the same issue.][/ref]

    Why is this a problem? If n is 0, the loop will run 0 times, so it
    won't dereference the pointer. As long as all other uses of the array
    are similar (iterating n times through the array), things should work
    fine. This is the justification for allowing malloc(0) to succeed; the
    caller doesn't have to special-case this situation, it just happens
    naturally when iterating.

    --
    Barry Margolin, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  10. #10

    Default Programmer stupidity (Re: malloc() / calloc() weirdness)

    net wrote... 
    >
    > Huh?
    >  
    >
    > What exactly happens?[/ref]

    Usually nothing. Sometimes I dump core on a SIGSEGV. gdb says:

    #0 0x400cc84a in _int_malloc () from /lib/libc.so.6
    (gdb) up
    #1 0x400cc16a in calloc () from /lib/libc.so.6
    (gdb) up
    #2 0x0804a06f in extractTcp (iph=0xbffff4b0, ropkt=0x808ded2 "#
    (\224h\213\212\020`xP\030`;", tal=0x80559a0)
    at src/extract.c:661
    661 struct tcphdr * tcph = calloc ( 1, sizeof(struct
    tcphdr) ) ;

    (The program uses pcaplib)
     
    >
    > You are probably crashing, and memory leaks have nothing to do with it.[/ref]

    Looking for memory leaks is just my little pea brain trying to work
    through what it thinks are the most common causes of malloc() causing
    a segment violation.
     
    >
    > What was the entire valgrind message?
    > You are probably corrupting heap, and not realizing that that's
    > what you did.[/ref]

    You look like Nostradamus to me right now. I've done a Google search
    on heap corruption and am busy reading. Most of what I've seen so
    far is generic, but that's probably the best place to start. If you
    know of a particularly good reference, though, I'd be grateful.

    I apologize to the other responders to my original post, since my
    unintentionally inaccurate description of the behavior I was seeing
    kind of got them going in the wrong direction.

    RTS
    Rent Guest

Similar Threads

  1. Replies: 1
    Last Post: February 25th, 10:39 PM
  2. Problem with malloc and memcpy
    By Eric in forum UNIX Programming
    Replies: 5
    Last Post: January 23rd, 08:12 AM
  3. segmentation fault on calloc
    By Mathieu in forum UNIX Programming
    Replies: 39
    Last Post: November 3rd, 09:47 PM
  4. calloc in C
    By Mathieu in forum UNIX Programming
    Replies: 2
    Last Post: November 3rd, 03:03 PM
  5. persistent malloc
    By Luiz Henrique de Figueiredo in forum UNIX Programming
    Replies: 5
    Last Post: July 30th, 10:07 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139