on Fri, Mar 08, 2002 at 03:58:12PM -0500, Greg A. Woods wrote:
> It may not have helped, but it doesn't hurt either -- I've not noticed
> any performance problems with using it on one of the most performance
> sensitive applications I run:  Xserver.  (That may be in part due to
> better code generation in GCC-2.95.3 vs. EGCS 1.1.2 though.)

The problem is, because stack-based buffers are "bad", more and more
structures are being moved to the heap, for which there isn't really a good
protection mechanism, imho.
That said, I think I'll be playing with a completely gcc-ssp compiled
userland soon.

> You mean like what pkgsrc/devel/electricfence can do?

yes, I think vsftpd has it's own implementation too.

> > but this is very inefficient and not so
> > portable and might fail too. (I think it would add 8192 bytes to each
> > malloc on i386.)
> 
> I don't find ElectricFence too big a pig, though it is slower for sure.

Well, I've been using ef and dmalloc to debug some code, and
I find they quickly uses up a lot of memory and can slow code down
dramatically. Try creating a large, heap-based linked list with it,
for example, then compile with profiling enabled.

> Gray Watson's Debug Malloc library is also very efficient and has caught
> a number of bugs in programs I've maintained over the years.

Yes, and I found dmalloc easier to use to trace pesky memory leaks and such
down. But I don't think it would be appropriate for set-[ug]id programs
because of how it uses getenv(), illustrating that it wasn't really written
as a protection mechanism.