«

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.

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/~a...FAQ-acllc.html

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 <> 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.

>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 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.

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 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.