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> ? On Tue, 18 Jun 2013 12:28:02 +0200 Cedric Blancher 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> ... > #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 > signals but fails to call the trap the proper number of times: 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 _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
