On Mon, 29 Jul 2013 15:34:46 +0200 Roland Mainz wrote:
> On Sat, Jul 27, 2013 at 6:17 PM, Glenn Fowler <[email protected]> wrote:
> >
> > the AT&T Software Technology ast alpha 2013-07-27 source release
> > has been posted to the download site
> > http://www.research.att.com/sw/download/alpha/
> > the package names and md5 checksums are
> > INIT 8cdf2460c146a7412ee1f2d37d19e3ce
> > ast-base 46a03d0e49840acedef8c0623cbef85c
> > ast-open f61766d8cb1f91c960a3a2a1385adcd6
> > ast-ksh 911d28c7263e90ec1e8037ad0b6db643
> > the md5 sums should match the ones listed on the download page
> >
> > still verifying builds on some architectures
> > should be ok on linux & solaris
> > for the next week or so stability/regression patches will take priority
> I hit (again) one of the nasty and hard to reproduce problems (which
> means: No... I don't have a testcase... ;-( ) related to job
> management:
> -- snip --
> 5841: /home/test001/ksh93/ast_ksh_20130727/build_i386_64bit_debug/arch/sol11
> fffffd7ffbcaa44a nanosleep (fffffd7fffdfd008, fffffd7fffdfcff8)
> fffffd7ffba70c90 tvsleep () + 40
> fffffd7ffbb0ec3c asorelax () + 3c
> fffffd7ffbb0ebbb asolock () + bb
> fffffd7ffbb19a36 dballoc () + 96
> fffffd7ffbb1a131 dbresize () + d1
> fffffd7ffbb10728 _ast_calloc () + 128
> fffffd7ffb88b064 jobsave_create () + 104
> fffffd7ffb88bd32 job_reap () + 6d2
> fffffd7ffb88b659 job_waitsafe () + 89
> fffffd7ffbca2326 __sighndlr () + 6
> fffffd7ffbc94ffc call_user_handler () + 2a4
> fffffd7ffbc95223 sigacthandler (12, fffffd7fffdfd7b0, fffffd7fffdfd450) + db
> --- called from signal handler with signal 18 (SIGCLD) ---
> fffffd7ffbb1a76b vmdbcheck () + 1bb
> fffffd7ffbb19e9e dbfree () + 27e
> fffffd7ffbb10c0c _ast_free () + 12c
> fffffd7ffb8e1021 sh_subshell () + 16f1
> fffffd7ffb8a83cf comsubst () + 10ff
> fffffd7ffb8a244d varsub () + 58d
> fffffd7ffb89fa16 copyto () + 10e6
> fffffd7ffb89ce83 sh_mactrim () + 2a3
> fffffd7ffb8ac9a6 sh_setlist () + 2e6
> fffffd7ffb8e9ca7 sh_exec () + 1367
> fffffd7ffb8ee803 sh_exec () + 5ec3
> fffffd7ffb8ef973 sh_exec () + 7033
> fffffd7ffb8ee831 sh_exec () + 5ef1
> fffffd7ffb8ee803 sh_exec () + 5ec3
> fffffd7ffb8f5eab sh_funscope_20120720 () + aeb
> fffffd7ffb8f3a9a sh_funct () + 37a
> fffffd7ffb8ebc94 sh_exec () + 3354
> fffffd7ffb844007 exfile () + 1147
> fffffd7ffb842e82 sh_main () + 1752
> 000000000040c0b2 main () + 92
> 000000000040becc ???????? ()
> -- snip --
> ... this hang occured because ksh93 tries to do job management from
> within the signal handler... which is IMO _far_ from being safe to
> do...
> David: Is there *ANY* way the job management can be moved out of the
> signal handler and just rely on the siginfo data ?
this one is simple
VMALLOC_OPTIONS=<anything-that-pushes-the-debug-discipline>
is not thread or signal safe
it may be possible to add signal safety, less optimistic about thread safety
=> don't use vmdebug if you are threading or signal storming or spawning
children <=
right now its not at the top of the todo list because past experience
show that any vmalloc coding in this area costs at least 2 weeks to get right
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
