Velocity Reviews

Velocity Reviews (
-   C Programming (
-   -   Re: calloc fails and returns NULL (

Ben Bacarisse 11-08-2012 02:13 AM

Re: calloc fails and returns NULL
k2ibegining <> writes:

> Thanks Ben for your reply !!
> 1. It's a production environment at our client base so we can not run
> a debugger onto their environment and neither can we ask them to
> install/use valgrind over there environment.

It would still be worth trying on a test machine. 9 times out of 10 you
have a bug that's corrupting memory and you might be able to find out
where even on a machine that does not trigger this particular allocation

> 2. We came to know this via truss output on one of the processes which
> shows ENOMEM error on sbrk routine. Eventually, we put debug
> statements in the code to check which condition is failing. We found
> that the code tried to a calloc() and as we check if the return
> pointer is NULL for calloc call we throw back an error code. The error
> code is specific to dynamic memory allocations such as malloc/calloc
> in our code. So we concretely came to know that calloc is failing as
> the pointer returned is NULL. an excerpt from truss output is as
> following

I don't want to sound wise after the event, but it sounds like you had
code with an unchecked error return, otherwise you would have known,
right away, that a calloc call had failed, no? Anyway, the point here
is that if that's what the code is like there may be other such places.
If so, fix them now. NOW! You may catch the error sooner and closer to
where the problem really is. Indeed, you may find the bug just by doing
this tidy up.

> kread(3, "\t M i n o r V e r s i o".., 4096) = 4096
> lseek(3, 0, 1) = 4338
> lseek(3, 0, 1) = 4338
> lseek(3, 0, 1) = 4338
> lseek(3, 280, 0) = 280
> kread(3, "\t U s e r N a m e = ".., 4096) = 4096
> lseek(3, 0, 1) = 4376
> lseek(3, 242, 0) = 242
> __libc_sbrk(0x00000000) Err#12 ENOMEM
> __libc_sbrk(0x00000000) Err#12 ENOMEM

That looks odd. I'd expect a number >0 as the argument to sbrk, but
it's no more that a curiosity. 9 times out of 10, the bug is somewhere
else but it shows up, ages later, in a failed allocation or free

> 3. yes you are right that if we can know the memory usage at the time
> of failure, I'm working on that right now to try to hold process up
> for sometime, as process immediately dies as soon as it starts. So
> basically so far we were not able to observe the behaviour of its
> usage in terms of memory. However, i'm planning to change code so that
> process can be up for a while and we can see the process memory usage
> at that point before it is going to do a calloc call !!
> Also the customer has opened a ticket with IBM to figure out if there
> is any significant difference between workign AIX server and
> problematic AIX server.

It may be a system or hardware fault, but you can't ever debug a program
with that in mind -- you must be forced into that conclusion by
unassailable evidence.

> Is it possible from the process source code to monitor it's own memory
> usage ?? the failure scenario is all the time same, we try to start
> the processes and they die as soon as they come up !! and all
> processes in our application our behaving the same way on problematic
> machine !

That's question for an AIX group.


All times are GMT. The time now is 07:25 PM.

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