Hi!
----
The following test case (reduced from a 3rd-party's customer
production script) uses _very_ long variable names (don't ask why) and
triggers an issue with memory allocations:
-- snip --
$ ksh -c 'v="$(for ((i=0 ; i< 150000; i++)); do printf "abc" ; done)"
; for ((j=0 ; j<500;j++)) ; do printf "%s%d=10\n" "$v" j ; done ;
print' | valgrind --track-origins=yes --read-var-info=yes
--main-stacksize=$((2**30)) ~/bin/ksh
==3288== Memcheck, a memory error detector
==3288== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3288== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3288== Command: /home/test001/bin/ksh
==3288==
==3288== Syscall param mount(type) points to unaddressable byte(s)
==3288== at 0x5613A4A: mount (in /lib64/libc-2.15.so)
==3288== by 0x4AADC5: fs3d_mount (fs3d.c:115)
==3288== by 0x4AABF3: fs3d (fs3d.c:57)
==3288== by 0x42E583: sh_init (init.c:1470)
==3288== by 0x40D5A9: sh_main (main.c:142)
==3288== by 0x40D450: main (pmain.c:45)
==3288== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3288==
==3288== Source and destination overlap in memcpy(0x0, 0x5e3c081, -8751)
==3288== at 0x4C2C400: memcpy@@GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3288== by 0x454E7C: nv_open (name.c:1438)
==3288== by 0x451FD5: sh_setlist (name.c:594)
==3288== by 0x477E61: sh_exec (xec.c:1154)
==3288== by 0x40F0D5: exfile (main.c:588)
==3288== by 0x40E29A: sh_main (main.c:360)
==3288== by 0x40D450: main (pmain.c:45)
==3288==
==3288== Invalid write of size 1
==3288== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3288== by 0x454E7C: nv_open (name.c:1438)
==3288== by 0x451FD5: sh_setlist (name.c:594)
==3288== by 0x477E61: sh_exec (xec.c:1154)
==3288== by 0x40F0D5: exfile (main.c:588)
==3288== by 0x40E29A: sh_main (main.c:360)
==3288== by 0x40D450: main (pmain.c:45)
==3288== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3288==
==3288==
==3288== Process terminating with default action of signal 11 (SIGSEGV)
==3288== Access not within mapped region at address 0x0
==3288== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3288== by 0x454E7C: nv_open (name.c:1438)
==3288== by 0x451FD5: sh_setlist (name.c:594)
==3288== by 0x477E61: sh_exec (xec.c:1154)
==3288== by 0x40F0D5: exfile (main.c:588)
==3288== by 0x40E29A: sh_main (main.c:360)
==3288== by 0x40D450: main (pmain.c:45)
==3288== If you believe this happened as a result of a stack
==3288== overflow in your program's main thread (unlikely but
==3288== possible), you can try to increase the size of the
==3288== main thread stack using the --main-stacksize= flag.
==3288== The main thread stack size used in this run was 1073741824.
==3288==
==3288== HEAP SUMMARY:
==3288== in use at exit: 0 bytes in 0 blocks
==3288== total heap usage: 424 allocs, 424 frees, 26,696 bytes allocated
==3288==
==3288== All heap blocks were freed -- no leaks are possible
==3288==
==3288== For counts of detected and suppressed errors, rerun with: -v
==3288== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2)
Segmentation fault
-- snip --
There are at least two issues:
1. It seems that there is an unprotected memory allocation... which
causes |memcpy()| to copy into a |NULL| pointer
2. |struct Cache_entry| has |short| (!!!!) for |size| and |len|
fields... is this really intended ?
-- snip --
struct Cache_entry
{
Dt_t *root;
Dt_t *last_root;
char *name;
Namval_t *np;
Namval_t *last_table;
Namval_t *namespace;
int flags;
short size;
short len;
} entries[NVCACHE];
short index;
short ok;
-- snip --
Note that "bash4" and "dash" run the testcase without problems and IMO
ksh93 should do the same (e.g. accept variable names of unlimited
length...).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
