|
From: Roland M. <rol...@nr...> - 2013-02-25 21:56:37
|
Hi! ---- The valgrind usage below shows two issues with valgrind (valgrind-3.7.0 on SuSE 12.2/AMD64/64bit, testing a 64bit ksh93 binary (see http://lists.research.att.com/pipermail/ast-developers/2013q1/002266.html)): 1. Some messages for |memcpy()| seem to use |signed int| as 3rd argument for |memcpy()| instead of the (unsigned) |size_t|: -- snip -- ==3508== Source and destination overlap in memcpy(0x0, 0x5e3c081, -8751) -- snip -- 2. Some messages reporting the stack size seem to use |signed int| for the stack size: -- snip -- ==3508== The main thread stack size used in this run was -2147483648. -- snip -- Example: -- 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**31)) ~/bin/ksh ==3508== Memcheck, a memory error detector ==3508== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3508== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3508== Command: /home/test001/bin/ksh ==3508== ==3508== Syscall param mount(type) points to unaddressable byte(s) ==3508== at 0x5613A4A: mount (in /lib64/libc-2.15.so) ==3508== by 0x4AADC5: fs3d_mount (fs3d.c:115) ==3508== by 0x4AABF3: fs3d (fs3d.c:57) ==3508== by 0x42E583: sh_init (init.c:1470) ==3508== by 0x40D5A9: sh_main (main.c:142) ==3508== by 0x40D450: main (pmain.c:45) ==3508== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3508== ==3508== Source and destination overlap in memcpy(0x0, 0x5e3c081, -8751) ==3508== at 0x4C2C400: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3508== by 0x454E7C: nv_open (name.c:1438) ==3508== by 0x451FD5: sh_setlist (name.c:594) ==3508== by 0x477E61: sh_exec (xec.c:1154) ==3508== by 0x40F0D5: exfile (main.c:588) ==3508== by 0x40E29A: sh_main (main.c:360) ==3508== by 0x40D450: main (pmain.c:45) ==3508== ==3508== Invalid write of size 1 ==3508== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3508== by 0x454E7C: nv_open (name.c:1438) ==3508== by 0x451FD5: sh_setlist (name.c:594) ==3508== by 0x477E61: sh_exec (xec.c:1154) ==3508== by 0x40F0D5: exfile (main.c:588) ==3508== by 0x40E29A: sh_main (main.c:360) ==3508== by 0x40D450: main (pmain.c:45) ==3508== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3508== ==3508== ==3508== Process terminating with default action of signal 11 (SIGSEGV) ==3508== Access not within mapped region at address 0x0 ==3508== at 0x4C2C4D3: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3508== by 0x454E7C: nv_open (name.c:1438) ==3508== by 0x451FD5: sh_setlist (name.c:594) ==3508== by 0x477E61: sh_exec (xec.c:1154) ==3508== by 0x40F0D5: exfile (main.c:588) ==3508== by 0x40E29A: sh_main (main.c:360) ==3508== by 0x40D450: main (pmain.c:45) ==3508== If you believe this happened as a result of a stack ==3508== overflow in your program's main thread (unlikely but ==3508== possible), you can try to increase the size of the ==3508== main thread stack using the --main-stacksize= flag. ==3508== The main thread stack size used in this run was -2147483648. ==3508== ==3508== HEAP SUMMARY: ==3508== in use at exit: 0 bytes in 0 blocks ==3508== total heap usage: 424 allocs, 424 frees, 26,696 bytes allocated ==3508== ==3508== All heap blocks were freed -- no leaks are possible ==3508== ==3508== For counts of detected and suppressed errors, rerun with: -v ==3508== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2) Segmentation fault -- snip -- ---- Bye, Roland ---------- Forwarded message ---------- From: Roland Mainz <rol...@nr...> Date: Mon, Feb 25, 2013 at 10:21 PM Subject: Script created by script which uses very long variable names causes crashes... To: ast...@re... Cc: Glenn Fowler <gs...@re...>, David Korn <dg...@re...> 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) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |