if you had built with nmake and had -g in CCFLAGS the src would have
compiled with -D_BLD_DEBUG and each malloc would be tagged with the
originating file and line number -- which would have lead you sh/init.c
if you are skipping nmake or hiding some options in a cc wrapper
(I'm guitly of this too) add -D_BLD_DEBUG when you compile with -g
(but don't use _BLD_DEBUG for production/timing)
the bug is indeed signal related but probably not for the reason you think
its an under-allocation related to the new siginfo code
here's a fix
homework assignment is to explain why adding 8 bytes works and 7 doesn't
(I'm not familiar with the svar_init() code or SH_SIG internal usage
--
static void siginfo_init(Shell_t *shp)
{
struct Svars *sp;
size_t dsize = sizeof(siginfo_t)+SIGNAME_MAX+8;
svar_init(shp,SH_SIG,shtab_siginfo,dsize);
sp = (struct Svars*)SH_SIG->nvfun->next;
sp->dsize = dsize;
}
--
On Sat, 14 Sep 2013 01:08:15 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= wrote:
> There is a BIG issue with signals in this release. A lot of signal
> related tests fail, with memory corruption:
> test basic begins at 2013-09-14+00:47:47
> corrupted data:region=0xfffffd7ffb590eb0:block=0xfffffd7ffb49c890:bad
> byte at=904:
> basic.sh[320]: ALRM signal not working
> test basic failed at 2013-09-14+00:48:46 with exit code 1 [ 109 tests 1 error
> ]
> test basic(shcomp) begins at 2013-09-14+00:48:46
> corrupted data:region=0xfffffd7ffb590eb0:block=0xfffffd7ffb49c890:bad
> byte at=904:
> shcomp-basic.ksh[320]: ALRM signal not working
> test basic(shcomp) failed at 2013-09-14+00:49:46 with exit code 1 [
> 109 tests 1 error ]
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
