Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   malloc call not returning (http://www.velocityreviews.com/forums/t503504-malloc-call-not-returning.html)

Norbert Leister 05-02-2007 08:16 AM

malloc call not returning
 

Hi NG,

I've the problem, that a malloc call is not returning.

<source-snip>

printf("a\n");
my_pointer = (struct_pointer)malloc(struct_size); /*size 1420*/
printf("b\n");
</source-snip>

I'm almost sure, that my program frees some memory, but if there is no
memory, the malloc should return some NULL-pointer.

The 'normal' output of the function is 'a' and 'b'. But sometimes (after
a while of running), the program stops after printing the 'a'. The other
threads of the programm are still responding to commands, but the one
who called the malloc does not reacts.

Have you somewhere had a similar problem?
Compiler: gcc-3.3.3-7 on Fedora Core 2


Greeting:


Norbert

Ian Collins 05-02-2007 08:20 AM

Re: malloc call not returning
 
Norbert Leister wrote:
>
> Hi NG,
>
> I've the problem, that a malloc call is not returning.
>
> <source-snip>
>
> printf("a\n");
> my_pointer = (struct_pointer)malloc(struct_size); /*size 1420*/
> printf("b\n");
> </source-snip>
>
> I'm almost sure, that my program frees some memory, but if there is no
> memory, the malloc should return some NULL-pointer.
>
> The 'normal' output of the function is 'a' and 'b'. But sometimes (after
> a while of running), the program stops after printing the 'a'. The other
> threads of the programm are still responding to commands, but the one
> who called the malloc does not reacts.
>
> Have you somewhere had a similar problem?
> Compiler: gcc-3.3.3-7 on Fedora Core 2
>

Attach your debugger and see what the application is doing.

--
Ian Collins.

Norbert Leister 05-02-2007 10:28 AM

Re: malloc call not returning
 
Ian Collins wrote:
> Attach your debugger and see what the application is doing.


it is some remotely executed code - that's why I'm using the printf to
see where the code is stopping

Greetings:


Norbert

Richard Tobin 05-02-2007 11:04 AM

Re: malloc call not returning
 
In article <f19hcs$6pb$1@anderson.hrz.tu-chemnitz.de>,
Norbert Leister <makarius@web.de> wrote:

>I've the problem, that a malloc call is not returning.


If malloc() is really not returning, the most likely problem is that
you've got a malloc()-related error somewhere else in the program that
is messing up malloc()'s data structures.

Run your program under some kind of memory-checking tool such as
valgrind.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Norbert Leister 05-02-2007 01:42 PM

Re: malloc call not returning
 
I did not knew, that I shoud'nt cast the pointer - because malloc is
returning some (void*) while my pointer is of some other type ... (and I
don't like implicite casts).

The 'if(NULL == my_pointer) ...' is straight after the output :) I did
not wanted to bore the NG with uninteresting code.

Greetings:


Makarius

CBFalconer wrote:
> Two fundamental errors. First, don't cast the return value from
> malloc. Doing so may have hidden compiler error reports, such as
> caused by failure to #include <stdlib.h>. Second, test the
> returned result - if it is NULL the malloc failed.
>


Chris Dollin 05-02-2007 02:02 PM

Re: malloc call not returning
 
Norbert Leister wrote:

> I did not knew, that I shoud'nt cast the pointer - because malloc is
> returning some (void*) while my pointer is of some other type ... (and I
> don't like implicite casts).


There are no implicit casts.

That's because casts are the name for the expressions `(Type) Expr`.

/Conversions/ can be implicit.

Implicit conversions can be very useful, reducing the verbosity of your
code and making it differently robusted against changes in the types of
its component variables.

For pointer types, it's important to note that a cast has much the same
effect as "shut up, I know what I'm doing", which is all very well
except when you make a mistake: classically, when you fail to declare
`malloc`, the compiler assumes it returns `int`, your cast to `Spoo*`
is silently accepted, and the assignment of the complete garbage value
to its pointer destination goes undetected until the Most Embarrasing
Moment.

[Yes, a friendly compiler will tell you that you've forgotten to
declare `malloc`, that you've cast an integer to a pointer, did
you mean that, sir? etc; but friendliness isn't required by the
Standard, which is quite happy if your implementation is an axe
weilding psychopath in its spare time, viz, whenever there's un
defined behaviour to fall into.]

--
"You're not supposed to /think/ about it, /The Beiderbeck Connection/
you're supposed to say NO!" Jill Swinburn

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN


Norbert Leister 05-02-2007 02:29 PM

Re: malloc call not returning
 
hi,

Chris Dollin wrote:
> [Yes, a friendly compiler will tell you that you've forgotten to
> declare `malloc`, that you've cast an integer to a pointer, did
> you mean that, sir? etc; but friendliness isn't required by the
> Standard, which is quite happy if your implementation is an axe
> weilding psychopath in its spare time, viz, whenever there's un
> defined behaviour to fall into.]
>




when I write

my_pointer = malloc(struct_size);

i get an error compiling the code with g++. I sometimes use compiling my
c-code in g++ go get some extendend compiler warnings. So i use a
typecast for all mallocs I'm using...

Greeting:


Norbert

Richard Tobin 05-02-2007 02:37 PM

Re: malloc call not returning
 
In article <f1a77h$vn6$1@anderson.hrz.tu-chemnitz.de>,
Norbert Leister <makarius@web.de> wrote:

>when I write
>
> my_pointer = malloc(struct_size);
>
>i get an error compiling the code with g++. I sometimes use compiling my
>c-code in g++ go get some extendend compiler warnings. So i use a
>typecast for all mallocs I'm using...


So you're using a C++ compiler to get more warnings about C code
despite the fact that some of them are wrong and stop your program
compiling? This seems a dubious trade-off to me.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Chris Dollin 05-02-2007 02:58 PM

Re: malloc call not returning
 
Norbert Leister wrote:

> hi,
>
> Chris Dollin wrote:
> > [Yes, a friendly compiler will tell you that you've forgotten to
> > declare `malloc`, that you've cast an integer to a pointer, did
> > you mean that, sir? etc; but friendliness isn't required by the
> > Standard, which is quite happy if your implementation is an axe
> > weilding psychopath in its spare time, viz, whenever there's un
> > defined behaviour to fall into.]
> >

> when I write
>
> my_pointer = malloc(struct_size);
>
> i get an error compiling the code with g++.


g++ isn't a C compiler.

> I sometimes use compiling my
> c-code in g++ go get some extendend compiler warnings.


Turn up the warnings for gcc, rather than use g++.

--
"It's just the beginning we've seen" - Colosseum, /Tomorrow's Blues/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN


JT 05-02-2007 04:40 PM

Re: malloc call not returning
 
On May 2, 2:29 pm, Norbert Leister <makar...@web.de> wrote:
> when I write
>
> my_pointer = malloc(struct_size);
>
> i get an error compiling the code with g++. I sometimes use compiling my
> c-code in g++ go get some extendend compiler warnings. So i use a
> typecast for all mallocs I'm using...


Dear Norbert:

Many posters have commented that it is bad idea
to compile C code using a C++ compiler.

Here is a concrete reason why: there are many serious
differences in semantics, and your program may
execute incorrectly.

See this list of differences between ISO C and ISO C++:
http://david.tribble.com/text/cdiffs.htm

- JT




All times are GMT. The time now is 05:13 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.