Discussion:
[ast-developers] Signals still do not work, again (Re: ast-ksh alpha 2013-06-13 source posted)
Cedric Blancher
2013-06-18 10:28:02 UTC
Permalink
ast-ksh alpha 2013-06-13 source posted to
http://www.research.att.com/sw/download/alpha/
still a work in progess, but progress has been made in the
handling of signals in libast/vmalloc and ksh
more comments later this morning ...
Much to my dismay signals still do not work:
1. A 64bit ksh on Suse 12.3 still hangs in signal.sh:
ced 15197 15195 3 12:07 pts/0 00:00:18
/home/ced/ced_ksh_sig/build9/arch/linux.i386-64/src/cmd/ksh93/ksh
./src/cmd/ksh93/tests/signal.sh
ced 15456 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15457 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15459 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15460 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15461 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15462 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15463 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15464 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15465 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15466 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15467 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15468 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15469 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15470 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15471 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15472 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15473 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15474 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15475 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15476 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15477 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15478 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15479 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15480 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15481 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15482 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15483 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15484 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15485 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15486 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15487 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15488 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15489 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15490 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15491 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15492 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15493 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15494 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15495 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15496 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15497 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15498 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15499 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15500 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15501 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15502 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15503 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15504 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15505 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15506 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15507 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15508 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15509 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15510 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15511 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15512 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15513 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15514 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15515 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15516 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15517 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15518 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15519 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15520 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>

The parent (pid=15197) hangs in the aso code. This is the same kind of
hang we've seen in the last two releases:
#0 0x00007f705a5c9570 in __nanosleep_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007f705a92ae47 in tvsleep (tv=0x0, rv=0x0) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/tm/tvsleep.c:63
#2 0x00007f705a994583 in asorelax (nsec=262144) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/aso/asorelax.c:46
#3 0x00007f705a994532 in asolock (lock=0x7f705a41003c, key=20130501,
type=4) at /home/ced/ced_ksh_sig/build9/src/lib/libast/aso/asolock.c:40
#4 0x00007f705a99c405 in dballoc (vm=0x7f705bd50dc0, size=144,
local=0) at /home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:333
#5 0x00007f705a9958ea in _ast_malloc (size=144) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/malloc.c:682
#6 0x00007f705b4bd658 in set_trapinfo (shp=0x7f705b759ac0 <sh>,
sig=40, info=0x7fff605c3cf0)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:91
#7 0x00007f705b4bdbce in sh_fault (sig=40, info=0x7fff605c3cf0,
context=0x7fff605c3bc0)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:231
#8 <signal handler called>
#9 sh_fault (sig=1514295168, info=0x0, context=0x0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:117
#10 <signal handler called>
#11 vmdbcheck (vm=0x7f705bd50dc0) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:565
#12 0x00007f705a99c422 in dballoc (vm=0x7f705bd50dc0, size=16,
local=0) at /home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:336
#13 0x00007f705a9958ea in _ast_malloc (size=16) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/malloc.c:682
#14 0x00007f705b4eec8a in nv_putval (np=0x7f705a453b80,
string=0x7f705a424f80 "RTMIN+6\n", flags=1)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/name.c:1952
#15 0x00007f705b4a1c11 in nv_putv (np=0x7f705a453b80,
value=0x7f705a424f80 "RTMIN+6\n", flags=1, nfp=0x7f705a4e08e5)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/nvdisc.c:157
#16 0x00007f705b4edd24 in nv_putval (np=0x7f705a453b80,
string=0x7f705a424f80 "RTMIN+6\n", flags=1)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/name.c:1606
#17 0x00007f705b4c7a5c in sh_setsiginfo (sip=0x7f705a4bc3f0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/init.c:2058
#18 0x00007f705b4be665 in sh_chktrap (shp=0x7f705b759ac0 <sh>) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:500
#19 0x00007f705b518fe4 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44bb10, flags=512) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2955
#20 0x00007f705b517c63 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44bae0, flags=512) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2626
#21 0x00007f705b517354 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44baa0, flags=4) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2464
#22 0x00007f705b4a1015 in exfile (shp=0x7f705b759ac0 <sh>,
iop=0x7f705a465730, fno=11) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/main.c:599
#23 0x00007f705b4a01bc in sh_main (ac=2, av=0x7fff605c5a78,
userinit=0x0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/main.c:371
#24 0x0000000000400751 in main (argc=2, argv=0x7fff605c5a78) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/pmain.c:45


2. The test script below still does not work. It should print a line
with 'success' but instead reports failure. I did some debugging and
the sh_fault() handler receives the proper number of USR1 and USR2
signals but fails to call the trap the proper number of times:
------------------------------------------------------------
set -o nounset

integer i

compound c=(
compound child=(
float sum=0.0
)
)
integer -r pid=$$
integer -r numprocs=256

trap '(( c.child.sum-=1.7 ))' USR1
trap '(( c.child.sum-=3.3 ))' USR2
trap '(( c.child.sum+=.sh.sig.status ))' CHLD

for (( i=0 ; i < numprocs ; i++ )) ; do
{
sleep $((numprocs / 64.))
kill -s USR1 ${pid}
kill -s USR2 ${pid}
exit 5
} &
done

float start=$SECONDS
while ! wait ; do
/usr/bin/true

if (( (SECONDS-start) > 20 )) ; then
print '# Aborting wait loop...'
break
fi
done

if (( c.child.sum == 0.0 )) ; then
printf '# success.\n'
exit 0
else
printf 'sum for all signals=%f (should be "0")\n' \
c.child.sum
exit 1
fi

# notreached
------------------------------------------------------------

Ced
--
Cedric Blancher <cedric.blancher at googlemail.com>
Institute Pasteur
Lionel Cons
2013-06-18 12:12:20 UTC
Permalink
Post by Cedric Blancher
ast-ksh alpha 2013-06-13 source posted to
http://www.research.att.com/sw/download/alpha/
still a work in progess, but progress has been made in the
handling of signals in libast/vmalloc and ksh
more comments later this morning ...
ced 15197 15195 3 12:07 pts/0 00:00:18
/home/ced/ced_ksh_sig/build9/arch/linux.i386-64/src/cmd/ksh93/ksh
./src/cmd/ksh93/tests/signal.sh
ced 15456 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15457 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15459 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15460 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15461 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15462 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15463 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15464 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15465 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15466 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15467 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15468 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15469 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15470 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15471 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15472 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15473 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15474 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15475 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15476 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15477 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15478 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15479 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15480 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15481 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15482 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15483 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15484 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15485 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15486 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15487 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15488 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15489 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15490 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15491 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15492 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15493 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15494 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15495 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15496 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15497 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15498 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15499 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15500 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15501 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15502 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15503 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15504 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15505 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15506 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15507 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15508 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15509 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15510 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15511 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15512 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15513 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15514 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15515 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15516 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15517 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15518 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15519 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
ced 15520 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
The parent (pid=15197) hangs in the aso code. This is the same kind of
#0 0x00007f705a5c9570 in __nanosleep_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007f705a92ae47 in tvsleep (tv=0x0, rv=0x0) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/tm/tvsleep.c:63
#2 0x00007f705a994583 in asorelax (nsec=262144) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/aso/asorelax.c:46
#3 0x00007f705a994532 in asolock (lock=0x7f705a41003c, key=20130501,
type=4) at /home/ced/ced_ksh_sig/build9/src/lib/libast/aso/asolock.c:40
#4 0x00007f705a99c405 in dballoc (vm=0x7f705bd50dc0, size=144,
local=0) at /home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:333
#5 0x00007f705a9958ea in _ast_malloc (size=144) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/malloc.c:682
#6 0x00007f705b4bd658 in set_trapinfo (shp=0x7f705b759ac0 <sh>,
sig=40, info=0x7fff605c3cf0)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:91
#7 0x00007f705b4bdbce in sh_fault (sig=40, info=0x7fff605c3cf0,
context=0x7fff605c3bc0)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:231
#8 <signal handler called>
#9 sh_fault (sig=1514295168, info=0x0, context=0x0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:117
#10 <signal handler called>
#11 vmdbcheck (vm=0x7f705bd50dc0) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:565
#12 0x00007f705a99c422 in dballoc (vm=0x7f705bd50dc0, size=16,
local=0) at /home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:336
#13 0x00007f705a9958ea in _ast_malloc (size=16) at
/home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/malloc.c:682
#14 0x00007f705b4eec8a in nv_putval (np=0x7f705a453b80,
string=0x7f705a424f80 "RTMIN+6\n", flags=1)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/name.c:1952
#15 0x00007f705b4a1c11 in nv_putv (np=0x7f705a453b80,
value=0x7f705a424f80 "RTMIN+6\n", flags=1, nfp=0x7f705a4e08e5)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/nvdisc.c:157
#16 0x00007f705b4edd24 in nv_putval (np=0x7f705a453b80,
string=0x7f705a424f80 "RTMIN+6\n", flags=1)
at /home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/name.c:1606
#17 0x00007f705b4c7a5c in sh_setsiginfo (sip=0x7f705a4bc3f0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/init.c:2058
#18 0x00007f705b4be665 in sh_chktrap (shp=0x7f705b759ac0 <sh>) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/fault.c:500
#19 0x00007f705b518fe4 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44bb10, flags=512) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2955
#20 0x00007f705b517c63 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44bae0, flags=512) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2626
#21 0x00007f705b517354 in sh_exec (shp=0x7f705b759ac0 <sh>,
t=0x7f705a44baa0, flags=4) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/xec.c:2464
#22 0x00007f705b4a1015 in exfile (shp=0x7f705b759ac0 <sh>,
iop=0x7f705a465730, fno=11) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/main.c:599
#23 0x00007f705b4a01bc in sh_main (ac=2, av=0x7fff605c5a78,
userinit=0x0) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/main.c:371
#24 0x0000000000400751 in main (argc=2, argv=0x7fff605c5a78) at
/home/ced/ced_ksh_sig/build9/src/cmd/ksh93/sh/pmain.c:45
2. The test script below still does not work. It should print a line
with 'success' but instead reports failure. I did some debugging and
the sh_fault() handler receives the proper number of USR1 and USR2
------------------------------------------------------------
set -o nounset
integer i
compound c=(
compound child=(
float sum=0.0
)
)
integer -r pid=$$
integer -r numprocs=256
trap '(( c.child.sum-=1.7 ))' USR1
trap '(( c.child.sum-=3.3 ))' USR2
trap '(( c.child.sum+=.sh.sig.status ))' CHLD
for (( i=0 ; i < numprocs ; i++ )) ; do
{
sleep $((numprocs / 64.))
kill -s USR1 ${pid}
kill -s USR2 ${pid}
exit 5
} &
done
float start=$SECONDS
while ! wait ; do
/usr/bin/true
if (( (SECONDS-start) > 20 )) ; then
print '# Aborting wait loop...'
break
fi
done
if (( c.child.sum == 0.0 )) ; then
printf '# success.\n'
exit 0
else
printf 'sum for all signals=%f (should be "0")\n' \
c.child.sum
exit 1
fi
# notreached
------------------------------------------------------------
Ced
--
Cedric Blancher <cedric.blancher at googlemail.com>
Institute Pasteur
_______________________________________________
ast-developers mailing list
ast-developers at lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
I noticed that if I run the USR1/USR2 test script under valgrind
control it reports some of of uninitalised values, for example
==31595== Conditional jump or move depends on uninitialised value(s)
==31595== at 0x43B723: job_chldtrap (jobs.c:232)
==31595== by 0x427A04: sh_chktrap (fault.c:484)
==31595== by 0x481AF7: sh_exec (xec.c:2955)
==31595== by 0x47FEA5: sh_exec (xec.c:2466)
==31595== by 0x47EFA4: sh_exec (xec.c:2222)
==31595== by 0x40F3E4: exfile (main.c:599)
==31595== by 0x40E58B: sh_main (main.c:371)
==31595== by 0x40D6C0: main (pmain.c:45)
==31595== Uninitialised value was created by a heap allocation
==31595== at 0x4C29C83: _ast_malloc (vg_replace_malloc.c:1000)
==31595== by 0x43E34D: job_post (jobs.c:1421)
==31595== by 0x48236E: _sh_fork (xec.c:3158)
==31595== by 0x48284C: sh_fork (xec.c:3260)
==31595== by 0x47D1FD: sh_exec (xec.c:1695)
==31595== by 0x47FEA5: sh_exec (xec.c:2466)
==31595== by 0x47EFA4: sh_exec (xec.c:2222)
==31595== by 0x40F3E4: exfile (main.c:599)
==31595== by 0x40E58B: sh_main (main.c:371)
==31595== by 0x40D6C0: main (pmain.c:45)

Does that explain some of the signal issues?

Lionel
Glenn Fowler
2013-06-18 14:44:30 UTC
Permalink
dballoc() in the trace output means the vmalloc debug method is in use

the vmalloc debug method is not signal (and possibly thread) safe
this is either a temporary or permanent limitation
recent vmalloc hacking has been with method=best vs signals

run the signal test with the shtests -v option
this will be the default in the next alpha

since you were'nt running the tests via shtests were you running
with export VMALLOC_OPTIONS=<something> ?
Post by Cedric Blancher
ast-ksh alpha 2013-06-13 source posted to
http://www.research.att.com/sw/download/alpha/
still a work in progess, but progress has been made in the
handling of signals in libast/vmalloc and ksh
more comments later this morning ...
ced 15197 15195 3 12:07 pts/0 00:00:18
/home/ced/ced_ksh_sig/build9/arch/linux.i386-64/src/cmd/ksh93/ksh
./src/cmd/ksh93/tests/signal.sh
ced 15456 15197 0 12:09 pts/0 00:00:00 [ksh] <defunct>
...
Post by Cedric Blancher
#4 0x00007f705a99c405 in dballoc (vm=0x7f705bd50dc0, size=144,
local=0) at /home/ced/ced_ksh_sig/build9/src/lib/libast/vmalloc/vmdebug.c:333
2. The test script below still does not work. It should print a line
with 'success' but instead reports failure. I did some debugging and
the sh_fault() handler receives the proper number of USR1 and USR2
this is from the linux signal(7)
it contrasts the realtime signals RTMIN..RTMAX from the other "standard" signals

Real-time signals are distinguished by the following:

1. Multiple instances of real-time signals can be queued. By
contrast, if multiple instances of a standard signal are
delivered while that signal is currently blocked, then only one
instance is queued.

3. Real-time signals are delivered in a guaranteed order. Multiple
real-time signals of the same type are delivered in the order
they were sent. If different real-time signals are sent to a
process, they are delivered starting with the lowest-numbered
signal. (I.e., low-numbered signals have highest priority.) By
contrast, if multiple standard signals are pending for a process,
the order in which they are delivered is unspecified.

{ USR1 USR2 } are standard signals
while the respective signal handler is executing the signal is blocked
(1.) means that if a bunch of USR1's arrive while USR1 is being handled
all but one are dropped (in other words, only one of many is queued)

so for a test with a storm of USR1's one would expect a wide range of
values for a USR1 caught counter -- such a test should use RTMIN..RTMAX
for deterministinc results -- determinism seems to be the rationale for
adding RTMIN..RTMAX in the first place

Loading...