Re: Debugging standard C library routines



Frederick Gotham wrote:
Richard Heathfield posted:


achintmehta@xxxxxxxxx said:


The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.

Initialise every pointer.



I wouldn't go so far as to advise to initialise _every_ pointer.

#define POVER(arr) ((arr) + sizeof(arr)/sizeof*(arr))

int *p;

for(p=array1;POVER(array1)!=p;++p) /* Something */ ;

for(p=array2;POVER(array2)!=p;++p) /* Something */ ;


Initializing every pointer does no harm, but it is unlikely to
improve the situation of the original poster. Here we have a
malloc/free problem, so he needs to debug that part of the
library. And it is not an uninitialized pointer probably,
but a double free, or a more serius problem.



Check every malloc/calloc/realloc to ensure it succeeded before you rely
on its return value.



If malloc'ing less than a kilobyte, I wouldn't bother.



In a debug setting is better to never check malloc, so, if there is any
failure the program crashes immediately at the point of failure.

In a production setting it is obvious that some recovery action must be
started when there is no more memory.



Check that every array access is within bounds (0 to n - 1, for an array
of n elements).



This is like saying to the kids:

Be a good kid and do not do any stupid actions ok?

HOW could that advise be implemented? It is all the difficulty of
C. Telling people "check every array access" leads to no concrete
solutions for the OP.


One should _always_ watch out for such things when looking back over one's code.



Set indeterminate ('dangling') pointers to NULL.



This is good advice. Start with KNOWN conditions.


In Debug Mode, maybe. It wastes valuable nanoseconds (if not microseconds) in Release Mode. Maybe something like the following would be a compromise:

#ifdef NDEBUG
#define DMODE(statement)
#else
#define DMODE(statement) statement
#endif

int main()
{
int *p;

...

free(p); DMODE(p=0);
}

.



Relevant Pages

  • Re: Memory Structure Pointer Problems
    ... typedef struct sta { ... char* name; ... int num_cmpnds; ... A pointer to a struct cmp is almost ...
    (comp.lang.c)
  • Re: C# - getting binary data from .lib
    ... Use Marshal.AllocHGlobal to allocate the memory and pass this IntPtr to the ... int retCode = create(id, scale, ptrImage); ... You now control the pointer returned. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Another spinoza challenge
    ... You should test against the int type's limits: ... typedef struct complex ... a pointer to an integer ... A macro is preferable because it is replaced by inline code, ...
    (comp.lang.c)
  • Re: C# - getting binary data from .lib
    ... int create(int id, int scale, unsigned char *image); ... unsigned char* ptrImage = NULL; ... // Read through entire pointer byte by byte and put into managed array ...
    (microsoft.public.dotnet.framework.interop)
  • Re: C# - getting binary data from .lib
    ... then there is a problem with the ptrImage ... int retCode = create(id, scale, ptrImage); ... You now control the pointer returned. ...
    (microsoft.public.dotnet.framework.interop)