[ast-developers] Copying .sh.sig data ==> Segmentation fault in ast-ksh.20130807

[Cedric Blancher]

ksh (ast-ksh.20130807) crashes on my Fedora laptop if I try to copy
the information in .sh.sig to an array for later use:

ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault

(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

Ced

[David Korn]

cc: cedric.blancher at gmail.com
Subject: Re: [ast-developers] Copying .sh.sig data ==> Segmentation fault in ast-ksh.20130807
--------

Post by Cedric Blancher
ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault
(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

Here is the stack trace:
#0 0x0000003ab5e33ba1 in __sigqueue (pid=9200, sig=10, val=...)
at ../sysdeps/unix/sysv/linux/sigqueue.c:47
#1 0x0000000000434d78 in job_kill (pw=0x821de0, sig=10)
at /home/gsf/src/cmd/ksh93/sh/jobs.c:1199
#2 0x00000000004345b1 in job_walk (shp=0x8212a0, file=0x820260,
fun=0x434c0c <job_kill>, arg=266, joblist=0x7ffff7f2ca38)
at /home/gsf/src/cmd/ksh93/sh/jobs.c:1003
#3 0x0000000000499716 in b_kill (argc=5, argv=0x7ffff7f2ca38,
context=0x821800) at bltins/trap.c:251
#4 0x0000000000475886 in sh_exec (shp=0x8212a0, t=0x7ffff7f2c930, flags=4)
at sh/xec.c:1341
#5 0x0000000000417fe5 in exfile (shp=0x8212a0, iop=0x7ffff7ef0aa0, fno=11)
at /home/gsf/src/cmd/ksh93/sh/main.c:584
#6 0x000000000041722d in sh_main (ac=2, av=0x7fffffffe0e8, userinit=0)
at /home/gsf/src/cmd/ksh93/sh/main.c:356
#7 0x00000000004162f9 in main (argc=2, argv=0x7fffffffe0e8)
at /home/gsf/src/cmd/ksh93/sh/pmain.c:26


I don't understand how sigqueue() can be core dumping.

The line is
r = sigqueue(pid,sig,sig_val);

union sigval sig_val;
sig_val.sival_int = shp->sigval;
Here is what the debugger shows for the value of sig_val
{sival_int = 4, sival_ptr = 0x4}

Can anyone see how this can core dump?

David Korn
dgk at research.att.com

[Roland Mainz]

Post by David Korn
cc: cedric.blancher at gmail.com
Subject: Re: [ast-developers] Copying .sh.sig data ==> Segmentation fault in ast-ksh.20130807
--------

Post by Cedric Blancher
ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault
(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

#0 0x0000003ab5e33ba1 in __sigqueue (pid=9200, sig=10, val=...)
at ../sysdeps/unix/sysv/linux/sigqueue.c:47
#1 0x0000000000434d78 in job_kill (pw=0x821de0, sig=10)
at /home/gsf/src/cmd/ksh93/sh/jobs.c:1199
#2 0x00000000004345b1 in job_walk (shp=0x8212a0, file=0x820260,
fun=0x434c0c <job_kill>, arg=266, joblist=0x7ffff7f2ca38)
at /home/gsf/src/cmd/ksh93/sh/jobs.c:1003
#3 0x0000000000499716 in b_kill (argc=5, argv=0x7ffff7f2ca38,
context=0x821800) at bltins/trap.c:251
#4 0x0000000000475886 in sh_exec (shp=0x8212a0, t=0x7ffff7f2c930, flags=4)
at sh/xec.c:1341
#5 0x0000000000417fe5 in exfile (shp=0x8212a0, iop=0x7ffff7ef0aa0, fno=11)
at /home/gsf/src/cmd/ksh93/sh/main.c:584
#6 0x000000000041722d in sh_main (ac=2, av=0x7fffffffe0e8, userinit=0)
at /home/gsf/src/cmd/ksh93/sh/main.c:356
#7 0x00000000004162f9 in main (argc=2, argv=0x7fffffffe0e8)
at /home/gsf/src/cmd/ksh93/sh/pmain.c:26
I don't understand how sigqueue() can be core dumping.

AFAIK it can't... it's possible that the debugger (gdb) got somehow
confused... possible causes are:
1. Wrong binary passed to gdb
2. -fomit-frame-pointer and/or -foptimize-sibling-calls were used by
either gcc/clang... try recompiling with "-fno-omit-frame-pointer
-fno-optimize-sibling-calls". The issue in this case is that some
debuggers can't find the accurate position in the code anymore if the
frame pointer isn't used to point to the correct reference frame
anymore.

[snip]

Post by David Korn
Can anyone see how this can core dump?

See http://lists.research.att.com/pipermail/ast-developers/2013q3/003020.html
... the issue is that trying to copy .sh.sig using typeset -c or
typeset -C comvar=.sh.sig is somehow a way to doomsday in
ast-ksh.2013-08-07 ...

----

Bye,
Roland

[Roland Mainz]

On Thu, Aug 8, 2013 at 11:40 PM, Cedric Blancher

Post by Cedric Blancher
ksh (ast-ksh.20130807) crashes on my Fedora laptop if I try to copy
ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault
(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

The stacktrace looks like this:
-- snip --
$ cat test1.sh
compound c
compound -a c.car
integer c.cari=0
trap 'typeset -c c.car[$((c.cari++))]=.sh.sig' USR1
kill -q4 -s USR1 $$
kill -q5 -s USR1 $$
true
print -v c
$ gdb --args ./arch/linux.i386-64/bin/ksh test1.sh
GNU gdb (GDB) SUSE (7.5.1-2.1.1)
[snip]
(gdb) run
Starting program:
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/arch/linux.i386-64/bin/ksh
test1.sh

Program received signal SIGUSR1, User defined signal 1.
0x00007ffff735f402 in __sigqueue (pid=55174, sig=10, val=...) at
../sysdeps/unix/sysv/linux/sigqueue.c:46
46 return INLINE_SYSCALL (rt_sigqueueinfo, 3, pid, sig,
__ptrvalue (&info));
(gdb) cont
Continuing.

Program received signal SIGUSR1, User defined signal 1.
0x00007ffff735f402 in __sigqueue (pid=55174, sig=10, val=...) at
../sysdeps/unix/sysv/linux/sigqueue.c:46
46 return INLINE_SYSCALL (rt_sigqueueinfo, 3, pid, sig,
__ptrvalue (&info));
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000000005227ad in vmregion (addr=0x7ffff7f1dfe0) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/lib/libast/vmalloc/vmbest.c:1105
1105 if(SGHOLD(seg,blk) && (pack =
(Pack_t*)PACK(blk)) && pack->best == (Vmbest_t*)vmdt )
(gdb) where
#0 0x00000000005227ad in vmregion (addr=0x7ffff7f1dfe0) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/lib/libast/vmalloc/vmbest.c:1105
#1 0x000000000051e9cb in _ast_free (data=0x7ffff7f1dfe0) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/lib/libast/vmalloc/malloc.c:740
#2 0x000000000044655e in _nv_unset (np=0x7ffff7f21138, flags=1) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/name.c:2658
#3 0x000000000044c50f in outval (name=0x7ffff7f18e1a "addr",
vname=0x7ffff7f18e11 "c.car[1].addr", wp=0x7fffffffc8d0)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvtree.c:873
#4 0x000000000044d56b in genvalue (argv=0x7ffff7f18f50,
prefix=0x7ffff7f18df0 "c.car[1]", n=0, wp=0x7fffffffc8d0)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvtree.c:1102
#5 0x000000000044e0b1 in walk_tree (np=0x7ffff7f297b0, xp=0x0,
flags=1) at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvtree.c:1267
#6 0x000000000044e488 in put_tree (np=0x7ffff7f297b0, val=0x0,
flags=0, fp=0x7ffff7f1ce80)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvtree.c:1338
#7 0x0000000000494140 in nv_putv (np=0x7ffff7f297b0, value=0x0,
flags=0, nfp=0xa) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvdisc.c:152
#8 0x0000000000443dd5 in nv_putval (np=0x7ffff7f297b0, string=0x0,
flags=0) at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/name.c:1688
#9 0x00000000004a5365 in array_putval (np=0x7ffff7f29690, string=0x0,
flags=0, dp=0x7ffff7f1d3c0)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/array.c:670
#10 0x0000000000494140 in nv_putv (np=0x7ffff7f29690, value=0x0,
flags=0, nfp=0xa) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/nvdisc.c:152
#11 0x00000000004463d7 in _nv_unset (np=0x7ffff7f29690, flags=0) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/name.c:2623
#12 0x0000000000448390 in nv_rename (np=0x7ffff7f29690, flags=512) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/name.c:3400
#13 0x000000000048ffd8 in setall (argv=0x7ffff7f18c70, flag=512,
troot=0x7ffff7ede3a0, tp=0x7fffffffcf00)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/bltins/typeset.c:725
#14 0x000000000048f032 in b_typeset (argc=3, argv=0x7ffff7f18c68,
context=0x8047c0 <sh+1376>)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/bltins/typeset.c:458
#15 0x0000000000468e5d in sh_exec (shp=0x804260 <sh>,
t=0x7ffff7f18b90, flags=4) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/xec.c:1360
#16 0x000000000047236c in sh_eval_20120720 (shp=0x804260 <sh>,
iop=0x7ffff7edc650, mode=0)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/xec.c:4148
#17 0x00000000004160a3 in sh_trap_20120720 (shp=0x804260 <sh>,
trap=0x7ffff7f1ce40 "typeset -c c.car[$((c.cari++))]=.sh.sig", mode=0)
at /home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/fault.c:862
#18 0x0000000000414fe4 in sh_chktrap (shp=0x804260 <sh>) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/fault.c:500
#19 0x000000000046ea91 in sh_exec (shp=0x804260 <sh>,
t=0x7ffff7f18830, flags=4) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/xec.c:2960
#20 0x000000000040f503 in exfile (shp=0x804260 <sh>,
iop=0x7ffff7edc4d0, fno=11) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/main.c:603
#21 0x000000000040e74e in sh_main (ac=2, av=0x7fffffffe1c8,
userinit=0x0) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/main.c:375
#22 0x000000000040d921 in main (argc=2, argv=0x7fffffffe1c8) at
/home/test001/work/ast_ksh_20130807/build_i386_64bit_debug/src/cmd/ksh93/sh/pmain.c:45
(gdb) print pack
$3 = (Pack_t *) 0xa
-- snip --

... this may be caused by "typeset -c" because it doesn't like .sh.sig ... ;-/

----

Bye,
Roland

[Roland Mainz]

On Thu, Aug 8, 2013 at 11:40 PM, Cedric Blancher

Post by Cedric Blancher
ksh (ast-ksh.20130807) crashes on my Fedora laptop if I try to copy
ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault
(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

The following variation of Cedric's testcase doesn't crash but doesn't
print the correct .sh.sig data either:
-- snip --
$ cat test1.sh
compound c
compound -a c.car
integer c.cari=0
integer trap_i

trap '(( trap_i=c.cari++ )) ; typeset -c "c.car[$trap_i]=.sh.sig"' USR1

kill -q4 -s USR1 $$
kill -q5 -s USR1 $$
true
print -v c
$ ./arch/linux.i386-64/bin/ksh -x test1.sh
+ typeset -C c
+ typeset -C -a c.car
+ c.cari=0
+ typeset -li c.cari
+ typeset -li trap_i
+ trap '(( trap_i=c.cari++ )) ; typeset -c "c.car[$trap_i]=.sh.sig"' USR1
+ kill -q4 -s USR1 55344
+ (( trap_i=c.cari++ ))
+ typeset -c 'c.car[0]=.sh.sig'
+ kill -q5 -s USR1 55344
+ (( trap_i=c.cari++ ))
+ typeset -c 'c.car[1]=.sh.sig'
+ true
+ print -v c
(
typeset -C -a car=(
(
)
(
)
)
typeset -l -i cari=2
)
-- snip --

Grumpf... ;-(

----

Bye,
Roland

[Irek Szczesniak]

Post by Roland Mainz
On Thu, Aug 8, 2013 at 11:40 PM, Cedric Blancher

Post by Cedric Blancher
ksh (ast-ksh.20130807) crashes on my Fedora laptop if I try to copy
ksh -c 'compound c ; compound -a c.car; integer c.cari=0; trap
"typeset -c c.car[\$((c.cari++))]=.sh.sig" USR1; kill -q4 -s USR1 $$;
kill -q5 -s USR1 $$; true ; print -v c'
Segmentation fault
(I don't have a usable stack trace because this is an optimized build.
Roland, could to have a look please?)

The following variation of Cedric's testcase doesn't crash but doesn't
-- snip --
$ cat test1.sh
compound c
compound -a c.car
integer c.cari=0
integer trap_i
trap '(( trap_i=c.cari++ )) ; typeset -c "c.car[$trap_i]=.sh.sig"' USR1
kill -q4 -s USR1 $$
kill -q5 -s USR1 $$
true
print -v c
$ ./arch/linux.i386-64/bin/ksh -x test1.sh
+ typeset -C c
+ typeset -C -a c.car
+ c.cari=0
+ typeset -li c.cari
+ typeset -li trap_i
+ trap '(( trap_i=c.cari++ )) ; typeset -c "c.car[$trap_i]=.sh.sig"' USR1
+ kill -q4 -s USR1 55344
+ (( trap_i=c.cari++ ))
+ typeset -c 'c.car[0]=.sh.sig'
+ kill -q5 -s USR1 55344
+ (( trap_i=c.cari++ ))
+ typeset -c 'c.car[1]=.sh.sig'
+ true
+ print -v c
(
typeset -C -a car=(
(
)
(
)
)
typeset -l -i cari=2
)
-- snip --
Grumpf... ;-(

Exactly the noise I would make in this situation. However, while cool,
.sh.sig is a new feature.

If you'd run the testcase with VMALLOC_OPTIONS=abort on Solaris 11 you
would've noticed that all copied data are zero'ed (testcase below).
My theory is that car[i]=.sh.sig copies the nv objects, including the
pointers to values, but the pointers still point to the siginfo data
and the data themselves are NOT copied as they should be:
VMALLOC_OPTIONS=abort ~/bin/ksh -c 'compound -a car ; integer i cari=0
; trap "(( i=cari++ )) ; car[i]=.sh.sig" USR1 USR2
; kill -q5 -s USR1 $$ ; kill -q19 -s USR2 $$ ; print -v car'
(
(
typeset -r -l -i 16 addr=16#0
typeset -r -l -i band=0
typeset -r code=QUEUE
typeset -r -i errno=0
typeset -r name=USR2
typeset -r -i pid=0
typeset -r -i signo=0
typeset -r -i status=0
typeset -r -i uid=0
value=(
typeset -r -i int=0
typeset -r -l -i 16 ptr=16#0
)
)
(
typeset -r -l -i 16 addr=16#0
typeset -r -l -i band=0
typeset -r code=QUEUE
typeset -r -i errno=0
typeset -r name=USR2
typeset -r -i pid=0
typeset -r -i signo=0
typeset -r -i status=0
typeset -r -i uid=0
value=(
typeset -r -i int=0
typeset -r -l -i 16 ptr=16#0
)
)
)

Irek