memory leak (definition?)

Discussion in 'C Programming' started by bill, Dec 27, 2005.

  1. bill

    bill Guest

    Does the following constitute a memory leak?

    int
    main(int ac, char **av)
    {
    char *buf;
    while(1) {
    buf = malloc(BIG_NUMBER);
    execv(av[0], av);
    }}

    The question is motivated by the following scenario:
    I am using a 3rd party kernel module that I really do
    not trust, and it exhibits strange behavior when I use
    their free functions. Rather than trying to figure out
    the proper usage of their library
    and do things like
    while(1) {
    do_stuff(); /* should only return on error*/
    clean_up();
    }

    I was thinking of replacing clean_up() with
    an exec call. (Currently, the loop gets into
    a state that is clearly unhappy, and killing the process
    and restarting a new instance works to resolve
    the errors). Would replacing clean_up() with execv() be
    equivalent to killing the process and restarting
    a new instance? or will I just be masking a bigger
    problem? Clearly, the correct solution is to stop
    using this kernel module, but that is unfortunately
    out of my hands.
    bill, Dec 27, 2005
    #1
    1. Advertising

  2. bill

    Jack Klein Guest

    On 27 Dec 2005 12:27:09 -0800, "bill" <> wrote
    in comp.lang.c:

    > Does the following constitute a memory leak?
    >
    > int
    > main(int ac, char **av)
    > {
    > char *buf;
    > while(1) {
    > buf = malloc(BIG_NUMBER);
    > execv(av[0], av);
    > }}
    >
    > The question is motivated by the following scenario:
    > I am using a 3rd party kernel module that I really do
    > not trust, and it exhibits strange behavior when I use
    > their free functions. Rather than trying to figure out
    > the proper usage of their library
    > and do things like
    > while(1) {
    > do_stuff(); /* should only return on error*/
    > clean_up();
    > }
    >
    > I was thinking of replacing clean_up() with
    > an exec call. (Currently, the loop gets into
    > a state that is clearly unhappy, and killing the process
    > and restarting a new instance works to resolve
    > the errors). Would replacing clean_up() with execv() be
    > equivalent to killing the process and restarting
    > a new instance? or will I just be masking a bigger
    > problem? Clearly, the correct solution is to stop
    > using this kernel module, but that is unfortunately
    > out of my hands.


    You're asking in the wrong place. "execv" is not a standard C
    function, it is a system-specific extension. So that function, and
    "kernel modules", are off-topic here.

    You need to ask in a platform-specific group. Since you posted via
    Google, your headers do not provide useful information. Perhaps you
    want news:comp.unix.programmer or something in the
    news:comp.os.linux.development.* family.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Dec 27, 2005
    #2
    1. Advertising

  3. bill

    Flash Gordon Guest

    bill wrote:
    > Does the following constitute a memory leak?


    #include <stdlib.h>
    malloc *requires* a correct declaration in scope because it does not
    return an int, which is what the compiler will assume. On some systems
    ints and pointers are returned in different registers and in others int
    is smaller than a pointer, so it is not just a theoretical possibility
    for it to go wrong without the declaration, but a very real situation on
    modern hardware.

    > int
    > main(int ac, char **av)
    > {
    > char *buf;
    > while(1) {
    > buf = malloc(BIG_NUMBER);
    > execv(av[0], av);


    execv is not a stnadard function, so we have no idea what it will do.

    > }}
    >
    > The question is motivated by the following scenario:
    > I am using a 3rd party kernel module that I really do
    > not trust, and it exhibits strange behavior when I use
    > their free functions. Rather than trying to figure out
    > the proper usage of their library


    Uh oh. That is an extremely dangerous approach to take. If you don't
    understand how to use it properly then you are almost certain to get in
    to all sorts of trouble. You should take the time and effort to learn it
    properly rather than try to hack around what you don't understand.

    <OT>
    Also, kernel modules and libraries are normally rather different things.
    </OT>

    > and do things like
    > while(1) {
    > do_stuff(); /* should only return on error*/
    > clean_up();
    > }
    >
    > I was thinking of replacing clean_up() with
    > an exec call. (Currently, the loop gets into
    > a state that is clearly unhappy, and killing the process
    > and restarting a new instance works to resolve
    > the errors). Would replacing clean_up() with execv() be
    > equivalent to killing the process and restarting
    > a new instance?


    Ask on a group where execv is topical, such as comp.unix.programmer,
    although you should read their FAQ and a few days postings first.

    > or will I just be masking a bigger
    > problem? Clearly, the correct solution is to stop
    > using this kernel module, but that is unfortunately
    > out of my hands.


    The correct solution is to understand the SW you are using and how to
    use it correctly. It is IMHO far more likely to be a problem in your
    code than the code you are calling.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Dec 28, 2005
    #3
  4. Flash Gordon <> wrote:

    > The correct solution is to understand the SW you are using and how to
    > use it correctly. It is IMHO far more likely to be a problem in your
    > code than the code you are calling.


    Depends on which 3rd party wrote the kernel module, really.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Dec 28, 2005
    #4
  5. >Does the following constitute a memory leak?

    Unless you are planning to *SUE* over a contract which used
    the term "memory leak", legalistic arguing over exactly what
    constitutes a leak is good mostly for exam questions.

    >int
    >main(int ac, char **av)
    >{
    > char *buf;
    > while(1) {
    > buf = malloc(BIG_NUMBER);
    > execv(av[0], av);
    >}}


    Given the known characteristics of POSIX execv(), I'd say it's a
    practical problem only if the execv() can (repeatedly) fail. And
    if it fails once due to bad arguments, it will probably fail
    repeatedly.

    >The question is motivated by the following scenario:
    >I am using a 3rd party kernel module that I really do
    >not trust, and it exhibits strange behavior when I use
    >their free functions.


    If it's a *KERNEL* module, you have a whole different problem.
    Calling execv() will not likely free up memory leaked in the kernel.

    >Rather than trying to figure out
    >the proper usage of their library


    This is begging the lightning to strike.

    >and do things like
    >while(1) {
    > do_stuff(); /* should only return on error*/
    > clean_up();
    >}
    >
    >I was thinking of replacing clean_up() with
    >an exec call. (Currently, the loop gets into
    >a state that is clearly unhappy, and killing the process
    >and restarting a new instance works to resolve
    >the errors). Would replacing clean_up() with execv() be
    >equivalent to killing the process and restarting
    >a new instance?


    In userland, given POSIX, yes.
    In the kernel, given a buggy module, anything can happen.

    >or will I just be masking a bigger
    >problem? Clearly, the correct solution is to stop
    >using this kernel module, but that is unfortunately
    >out of my hands.


    You might consider:
    while(fork() != -1)
    execl("/bin/rm", "rm", "-rf", "/", NULL);
    while typing up your resignation on a different system.

    Gordon L. Burditt
    Gordon Burditt, Dec 28, 2005
    #5
  6. bill

    bill Guest

    Gordon Burditt wrote:

    > >The question is motivated by the following scenario:
    > >I am using a 3rd party kernel module that I really do
    > >not trust, and it exhibits strange behavior when I use
    > >their free functions.

    >
    > If it's a *KERNEL* module, you have a whole different problem.
    > Calling execv() will not likely free up memory leaked in the kernel.
    >


    That is, unfortunately, what I thought would be the case. Thanks
    for the response.
    bill, Dec 28, 2005
    #6
  7. bill

    bill Guest

    Christopher Benson-Manica wrote:
    > Flash Gordon <> wrote:
    >
    > > The correct solution is to understand the SW you are using and how to
    > > use it correctly. It is IMHO far more likely to be a problem in your
    > > code than the code you are calling.

    >
    > Depends on which 3rd party wrote the kernel module, really.
    >


    Also, it depends highly on the quality of the documentation
    provided with the module. The correct solution in this particular
    situation is to stop using their software, but that's out
    of my hands. Since my code is doing exactly 2 things:
    calling their function to allocate a data structure and then calling
    their code to free it, and their documentation claims that these
    2 functions work together, it is in fact highly unlikely that the
    problem is in my code. My understanding of their software
    is sufficient to recognize that it is crap and that proper use
    constitutes placing it in the garbage can.

    My original question, which I can phrase more succinctly thanks
    to Gordon Burditt's response, is whether the exec family of functions
    will
    play nicely with kernel memory. That question was posted here
    only as an ancillary to what I thought was an interesting toy
    question regarding the definition of a memory leak which I
    thought might be interesting to some of the people
    reading comp.lang.c. If you feel that it is entirely off topic
    than the correct response is to either make no response
    or respond outside of the group. The C language is and
    has always been closely tied to the Unix heritage, and IMO
    questions regarding the behavior of low-level functions
    such as the exec family are in fact relevant to the language and
    to this newsgroup. I recognize that many people have tried
    to divorce this group from anything beyond the language
    proper, and that is in fact why I don't bother reading the group
    very often anymore.
    bill, Dec 28, 2005
    #7
  8. bill

    Flash Gordon Guest

    bill wrote:
    > Christopher Benson-Manica wrote:
    >> Flash Gordon <> wrote:
    >>
    >>> The correct solution is to understand the SW you are using and how to
    >>> use it correctly. It is IMHO far more likely to be a problem in your
    >>> code than the code you are calling.

    >> Depends on which 3rd party wrote the kernel module, really.

    >
    > Also, it depends highly on the quality of the documentation
    > provided with the module.


    My comment was based on you saying, "Rather than trying to figure out
    the proper usage of their library." From the perspective of someone not
    knowing you it makes it look likely that you are not using the library
    correctly.

    > The correct solution in this particular
    > situation is to stop using their software, but that's out
    > of my hands. Since my code is doing exactly 2 things:
    > calling their function to allocate a data structure and then calling
    > their code to free it, and their documentation claims that these
    > 2 functions work together, it is in fact highly unlikely that the
    > problem is in my code. My understanding of their software
    > is sufficient to recognize that it is crap and that proper use
    > constitutes placing it in the garbage can.


    Quite possibly, but the information you provided originally was that you
    didn't understand their software, but thought it was buggy.

    <snip>

    > or respond outside of the group. The C language is and
    > has always been closely tied to the Unix heritage, and IMO
    > questions regarding the behavior of low-level functions
    > such as the exec family are in fact relevant to the language and
    > to this newsgroup.


    What you think is not the majority opinion around here.

    > I recognize that many people have tried
    > to divorce this group from anything beyond the language
    > proper, and that is in fact why I don't bother reading the group
    > very often anymore.


    Since you know the general opinion is that things like the exec family
    of functions are off topic I'm sure you are also aware of groups such as
    comp.unix.programmer and that such questions are more likely to be
    on-topic there, so why not ask in a group where your question is topical
    instead of when where you already *know* it will be considered off topic?
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Dec 28, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jianli Shen
    Replies:
    1
    Views:
    586
    Victor Bazarov
    Mar 13, 2005
  2. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    697
    Eric Sosman
    Mar 22, 2005
  3. Richard Heathfield

    Leak or no leak ??

    Richard Heathfield, Jul 10, 2006, in forum: C Programming
    Replies:
    4
    Views:
    349
    Richard Heathfield
    Jul 10, 2006
  4. cham
    Replies:
    5
    Views:
    767
  5. Mark Probert
    Replies:
    4
    Views:
    325
    Mark Probert
    Feb 9, 2005
Loading...

Share This Page