This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/20544] RFE: atexit, __cxa_atexit, on_exit detect NULL function pointer argument


https://sourceware.org/bugzilla/show_bug.cgi?id=20544

--- Comment #8 from John Reiser <jreiser at BitWagon dot com> ---
(In reply to Florian Weimer from comment #4)
> If it is only about finding the culprit, a conditional breakpoint or a
> Systemtap script should help here.
> 
> I don't think the code generated by GCC checks the return value of
> __cxa_atexit, so an error return would not help anyway, we would have to
> terminate the process.

It's not just about finding the culprit today.  It's also about the next time,
and the time after that, etc.  I consider that a couple CPU cycles spent
testing for NULL, plus the development and maintenance burden of the code to
handle the case when the pointer is NULL, are worthwhile here.  If nothing
else, then the call site in exit() should check as a last resort in order to
prevent SIGSEGV.  
I prefer to get a diagnostic on stderr and then skip over the NULL pointer, but
I can accept a "graceful" abort().

[Aside: in the particular case of x86_64, I consider that "check for NULL
pointer" by default should be extended to include "check for virtual address
width > 48 bits".  All x86_64 implementations that exist or are in development
today use at most 48 bits of virtual address (see /proc/cpuinfo on Linux). 
Checking can be done inexpensively by "if ((unsigned long)ptr >> 48)".  This
detects all negative 64-bit signed integers, many UTF-8 text strings, most
double precision floating point numbers.]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]