On 18 June 2013 12:28, Cedric Blancher <[email protected]> wrote: > On 18 June 2013 04:34, Glenn Fowler <[email protected]> wrote: >> >> 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 <[email protected]> > Institute Pasteur > _______________________________________________ > ast-developers mailing list > [email protected] > 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 _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
