corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Checking malloc success and adding perror()
Date Fri, 20 Feb 2015 17:12:45 GMT
Good point.

The alternative to all of those strings is to have AllocFailure() capture the location from
which it is being called and, if possible, provide some amount of stack walkback.  That means
there is a file of symbols and such somewhere that can be used as part of crash analysis by
the developers. 

I am assuming this is done in release code, although there are debugging tests where one provokes
memory exhaustion to see how the application fails.

 - Dennis

PS: For windows, Online Crash Analysis support works with that and automatically collects
crash data minidumps in a database for the producers of the software to go in and see what
bad things are happening with actual users.  However I don't recall ever seeing a Windows
Error Reporting (WER) crasher message in any use of Windows 8, so that may be a disappearing
service.  That or software producers are (1) paranoid about having Microsoft have so much
information or (2) unwilling to receive crash data from their users in the first place.  The
new security technique of rearranging sections of code images on loading may have something
to do with how this works nowadays, also.

-----Original Message-----
From: jan i [] 
Sent: Friday, February 20, 2015 01:21
To:; Dennis Hamilton
Subject: Re: Checking malloc success and adding perror()

On 19 February 2015 at 20:26, Dennis E. Hamilton <>

> Some small points.
>  1. On the ability to trace where the memory allocation failed, it would
> be handy to take advantage of preprocessor variables to provide origin
> information relative to the source code.
> That might be (using the previous example), with a header file having
> something like
>   01 void* CheckedAlloc(size_t n, char* loc)
>   02 {  void* p = malloc(n);
>   03    if (p == NULL)
>   04       AllocFailure(loc);
>   05    return p;
>   06    }
>   10 #define ChkAlloc(n) (CheckedAlloc((n), #__FILE__ ":" #__LINE__ ))
I would recommend not doing this, it will work, but it will make the const
part of our lib explode.

If we were to do it, we would need to do it, not only for this function but
in general for all functions that could self terminate (or whatever we
decide to do later), and that would be a huge overhead for nearly nothing.

glibc used to have a stackframetrace() function, that we used heavely in
gdb, the function make a stacktrace, with different information depending
on if the code was compiled with debug or not.

jan i.

[ ... ]

View raw message