Date: Sun, 6 Mar 2005 04:32:06 +0100 From: Maxime Henrion <mux@FreeBSD.org> To: Sean McNeil <sean@mcneil.com> Cc: current@freebsd.org Subject: Re: /usr/src/lib/libc/string/strsignal.c:96 Message-ID: <20050306033206.GX31320@elvis.mu.org> In-Reply-To: <1110077033.64671.0.camel@server.mcneil.com> References: <1110060467.23311.5.camel@server.mcneil.com> <20050306002756.GV31320@elvis.mu.org> <1110077033.64671.0.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean McNeil wrote: > On Sun, 2005-03-06 at 01:27 +0100, Maxime Henrion wrote: > > Sean McNeil wrote: > > > Hi folks, > > > > > > It looks like strsignal is busted. All I have to do is hit ctrl-c while > > > running gmake and I get this core: > > > > > > #0 strsignal (num=2) at /usr/src/lib/libc/string/strsignal.c:96 > > > ebuf = "Interrupt", '\0' <repeats 2038 times> > > > tmp = "2\000\000\000\000\000\000\000\002\000\000\000\000\000\000 > > > \000\000\000\000" > > > signum = 0 > > > n = 4326031 > > > t = 0x7fffffffd151 "" > > > p = 0x800d5b82f <Address 0x800d5b82f out of bounds> > > > > > > This is because n is uninitialized when num > 0 && num < sys_nsig. > > > > Indeed. Can you confirm that this patch fixes the problem? > > > > %% > > --- strsignal.c.orig Tue Mar 1 20:28:14 2005 > > +++ strsignal.c Sun Mar 6 01:24:18 2005 > > @@ -64,7 +64,7 @@ > > #endif > > > > if (num > 0 && num < sys_nsig) { > > - strlcpy(ebuf, > > + n = strlcpy(ebuf, > > #if defined(NLS) > > catgets(catd, 2, num, sys_siglist[num]), > > #else > > %% > > Yes, this has the desired affect and no more core dump :) I just committed this fix plus I changed the type of n while I was here so that it is a size_t as it should. Thanks, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050306033206.GX31320>