Date: 24 Sep 1996 14:17:52 +0100 From: Paul Richards <p.richards@elsevier.co.uk> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: current@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.3 malloc.c Message-ID: <57iv94rr0f.fsf@tees.elsevier.co.uk> In-Reply-To: Poul-Henning Kamp's message of Mon, 23 Sep 1996 22:00:34 %2B0200 References: <4455.843508834@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp <phk@critter.tfs.com> writes: > I would actually like to make the 'A' option default, so that all > problems are reason for a core-dump. Although some programs handle > a malloc error, a lot doesn't. I think it makes a lot more sense > to core-dump a process that gets an malloc error these days, than > let it do it itself later on. If you can, please enable it and > tell me if anything unexpected breaks. What sort of problems are you talking about? Any decent programmer checks malloc return values and you shouldn't take control away from the programmer by making the library function core dump. For something like Apache, which maintains its own memory pool, core dumping the server because of a malloc error will take the site down when in fact it could probably have carried on quite happily even if that malloc call had failed. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57iv94rr0f.fsf>