[ast-developers] valgrind hit when reading types...

[Roland Mainz]

Hi!

----

The following testcase...
-- snip --
typeset -T x_t=(
integer i
)

typeset -T b_t=(
compound -a ar

function move
{
integer fx=$1
integer fy=$2
integer fz=$3
integer tx=$4
integer ty=$5
integer tz=$6

typeset -m '_.ar[tx][ty][tz].value=_.ar[fx][fy][fz].value'
#unset '_.ar[fx][fy][fz]'
}
)

function main
{
compound c
b_t c.b

x_t c.b.ar[100][200][300].value=( i=9 )
print "i=${c.b.ar[100][200][300].value.i}"

for ((i=0 ; i < 10 ; i++ )) ; do
c.b.move 100 200 300 400 500 600
c.b.move 400 500 600 1000 1100 1200
c.b.move 1000 1100 1200 100 200 300
done

out1=$(print -v c)
read -C d <<<"$out1"
# print -v d
}

main
-- snip ---
... triggers a valgrind hit in ast-ksh.2013-07-27 on SuSE
12.3/AMD64/64bit when reading a user-defined type:
-- snip --
$ valgrind --num-callers=200 test1.sh
==3587== Memcheck, a memory error detector
==3587== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3587== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3587== Command: /home/test001/bin/ksh valgrind_unset.sh
[snip]
i=9
==3587== Conditional jump or move depends on uninitialised value(s)
==3587== at 0x42E39D: sh_lex (lex.c:505)
==3587== by 0x452AA3: simple (parse.c:1558)
==3587== by 0x45235E: item (parse.c:1405)
==3587== by 0x44F72C: term (parse.c:594)
==3587== by 0x44F610: list (parse.c:564)
==3587== by 0x44F4A6: sh_cmd (parse.c:514)
==3587== by 0x44F087: sh_parse (parse.c:403)
==3587== by 0x471E12: sh_eval_20120720 (xec.c:4126)
==3587== by 0x449983: read_tree (nvtree.c:67)
==3587== by 0x488F93: sh_readline (read.c:338)
==3587== by 0x48873E: b_read (read.c:177)
==3587== by 0x4689E0: sh_exec (xec.c:1360)
==3587== by 0x46BAC1: sh_exec (xec.c:2227)
==3587== by 0x471840: sh_funscope_20120720 (xec.c:4040)
==3587== by 0x46FA27: sh_funct (xec.c:3376)
==3587== by 0x469504: sh_exec (xec.c:1559)
==3587== by 0x40F471: exfile (main.c:603)
==3587== by 0x40E6BC: sh_main (main.c:375)
==3587== by 0x40D890: main (pmain.c:45)
==3587==
-- snip --

----

Bye,
Roland

[Roland Mainz]

Post by Roland Mainz
The following testcase...
-- snip --

[snip]

Post by Roland Mainz
-- snip ---
... triggers a valgrind hit in ast-ksh.2013-07-27 on SuSE
-- snip --
$ valgrind --num-callers=200 test1.sh
==3587== Memcheck, a memory error detector
==3587== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3587== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3587== Command: /home/test001/bin/ksh valgrind_unset.sh
[snip]
i=9
==3587== Conditional jump or move depends on uninitialised value(s)
==3587== at 0x42E39D: sh_lex (lex.c:505)
==3587== by 0x452AA3: simple (parse.c:1558)
==3587== by 0x45235E: item (parse.c:1405)
==3587== by 0x44F72C: term (parse.c:594)
==3587== by 0x44F610: list (parse.c:564)
==3587== by 0x44F4A6: sh_cmd (parse.c:514)
==3587== by 0x44F087: sh_parse (parse.c:403)
==3587== by 0x471E12: sh_eval_20120720 (xec.c:4126)
==3587== by 0x449983: read_tree (nvtree.c:67)
==3587== by 0x488F93: sh_readline (read.c:338)
==3587== by 0x48873E: b_read (read.c:177)
==3587== by 0x4689E0: sh_exec (xec.c:1360)
==3587== by 0x46BAC1: sh_exec (xec.c:2227)
==3587== by 0x471840: sh_funscope_20120720 (xec.c:4040)
==3587== by 0x46FA27: sh_funct (xec.c:3376)
==3587== by 0x469504: sh_exec (xec.c:1559)
==3587== by 0x40F471: exfile (main.c:603)
==3587== by 0x40E6BC: sh_main (main.c:375)
==3587== by 0x40D890: main (pmain.c:45)
==3587==
-- snip --

Looking at the code...
-- snip --
502 case S_NL:
503 /* skip over new-lines */
504 lp->lex.last_quote = 0;
505 while(shp->inlineno++,fcget()=='\n');
506 fcseek(-LEN);
507 if(n==S_NLTOK)
508 {
509 lp->comp_assign = 0;
510 return(lp->token='\n');
511 }
-- snip --
... the issue here is |fcget()| in line 505 which somehow accesses a
memory area which has not been filled with data (maybe an off-by-one
mistake) ?

----

Bye,
Roland