On Thu, Apr 4, 2013 at 12:34 AM, Roland Mainz <[email protected]> wrote:
> On Fri, Mar 22, 2013 at 1:36 AM, Roland Mainz <[email protected]>
> wrote:
>> On Sat, Mar 9, 2013 at 9:52 PM, Roland Mainz <[email protected]>
>> wrote:
>>> On Mon, Feb 25, 2013 at 8:51 PM, Roland Mainz <[email protected]>
>>> wrote:
>>>> On Fri, Feb 22, 2013 at 10:14 PM, Glenn Fowler <[email protected]>
>>>> wrote:
>>>>> On Thu, 21 Feb 2013 04:19:00 +0100 Roland Mainz wrote:
>>>>>> On Mon, Feb 18, 2013 at 5:51 PM, Glenn Fowler <[email protected]>
>>>>>> wrote:
>>>>>> >
>>>>>> > 2013-02-14 alpha posted to www.research.att.com/download/alpha/
>>>>>> > INIT.2013-02-14.tgz
>>>>>> > ast-ksh.2013-02-14.tgz
>>>>>> > this is a work in progress
>>>>>> > there are known problems on some architectures
>>>>>
>>>>>> On SuSE 12.2 Linux/AMD64/64bit I get a couple of valgrind hits in the
>>>>>> spawnvex subsystem:
>>>>>> -- snip --
>>>>>> $ valgrind --track-origins=yes --read-var-info=yes ~/bin/ksh -c 'ls -l
>>>>>> ; true'
>>>>>> ==19925== Memcheck, a memory error detector
>>>>>> ==19925== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>>>>>> ==19925== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
>>>>>> info
>>>>>> ==19925== Command: /home/test001/bin/ksh -c ls\ -l\ ;\ true
>>>>>> ==19925==
>>>>>> [snip]
>>>>>> ==19925==
>>>>>> ==19925== Conditional jump or move depends on uninitialised value(s)
>>>>>> ==19925== at 0x4DC865: spawnvex (spawnvex.c:1100)
>>>>>> ==19925== by 0x4653D3: _spawnveg (path.c:151)
>>>>>> ==19925== by 0x468973: path_spawn (path.c:1228)
>>>>>> ==19925== by 0x480B4A: sh_ntfork (xec.c:3824)
>>>>>> ==19925== by 0x479F15: sh_exec (xec.c:1675)
>>>>>> ==19925== by 0x47BC7A: sh_exec (xec.c:2200)
>>>>>> ==19925== by 0x40F0D5: exfile (main.c:588)
>>>>>> ==19925== by 0x40E29A: sh_main (main.c:360)
>>>>>> ==19925== by 0x40D450: main (pmain.c:45)
>>>>>> ==19925== Uninitialised value was created by a stack allocation
>>>>>> ==19925== at 0x4DC6C2: spawnvex (spawnvex.c:793)
>>>> [snip]
>>>>>
>>>>> roland, I'm having line sync probs between my src and the valgrind lines
>>>>> can you identify the varialble that is claimed to be uninitialized
>>>>> thanks
>>>>
>>>> valgrind hits and line numbers for ast-ksh.2013-02-22 look like this:
>>>> -- snip --
>>>> $ valgrind --track-origins=yes --read-var-info=yes
>>>> ./arch/linux.i386-64/bin/ksh -c 'ls -l ; true'
>>>> ==2409== Memcheck, a memory error detector
>>>> ==2409== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>>>> ==2409== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
>>>> ==2409== Command: ./arch/linux.i386-64/bin/ksh -c ls\ -l\ ;\ true
>>>> ==2409==
>>>> [snip]
>>>> ==2409==
>>>> ==2409== Conditional jump or move depends on uninitialised value(s)
>>>> ==2409== at 0x4DC851: spawnvex (spawnvex.c:1100)
>>>> ==2409== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2409== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2409== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2409== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2409== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2409== by 0x40F0D5: exfile (main.c:588)
>>>> ==2409== by 0x40E29A: sh_main (main.c:360)
>>>> ==2409== by 0x40D450: main (pmain.c:45)
>>>> ==2409== Uninitialised value was created by a stack allocation
>>>> ==2409== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> ==2409==
>>>> ==2409== Conditional jump or move depends on uninitialised value(s)
>>>> ==2409== at 0x4DCC77: spawnvex (spawnvex.c:1193)
>>>> ==2409== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2409== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2409== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2409== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2409== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2409== by 0x40F0D5: exfile (main.c:588)
>>>> ==2409== by 0x40E29A: sh_main (main.c:360)
>>>> ==2409== by 0x40D450: main (pmain.c:45)
>>>> ==2409== Uninitialised value was created by a stack allocation
>>>> ==2409== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> ==2409==
>>>> ==2410== Conditional jump or move depends on uninitialised value(s)
>>>> ==2410== at 0x4DC8AB: spawnvex (spawnvex.c:1118)
>>>> ==2410== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2410== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2410== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2410== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2410== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2410== by 0x40F0D5: exfile (main.c:588)
>>>> ==2410== by 0x40E29A: sh_main (main.c:360)
>>>> ==2410== by 0x40D450: main (pmain.c:45)
>>>> ==2410== Uninitialised value was created by a stack allocation
>>>> ==2410== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> ==2410==
>>>> total 1536
>>>> drwxr-xr-x 3 test001 users 4096 Feb 24 23:06 arch
>>>> drwxr-xr-x 2 test001 users 4096 Feb 24 23:07 bin
>>>> -rw-r--r-- 1 test001 users 1537649 Feb 25 02:29 buildlog.log
>>>> drwxr-xr-x 3 test001 users 4096 Feb 24 23:04 lib
>>>> -rw-r--r-- 1 test001 users 854 Feb 23 08:20 README
>>>> drwxr-xr-x 4 test001 users 4096 Feb 24 23:04 src
>>>> drwxr-xr-x 3 test001 users 4096 Feb 25 05:29 tmp
>>>> -rw-r--r-- 1 test001 users 3851 Feb 24 23:06
>>>> tmp_gnulinux_builtin_header.h
>>>> -- snip --
>>>>
>>>> First hit is:
>>>> -- snip --
>>>> ==2461== Conditional jump or move depends on uninitialised value(s)
>>>> ==2461== at 0x4DC851: spawnvex (spawnvex.c:1100)
>>>> ==2461== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2461== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2461== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2461== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2461== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2461== by 0x40F0D5: exfile (main.c:588)
>>>> ==2461== by 0x40E29A: sh_main (main.c:360)
>>>> ==2461== by 0x40D450: main (pmain.c:45)
>>>> ==2461== Uninitialised value was created by a stack allocation
>>>> ==2461== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> -- snip --
>>>> ... which seems to be the |flags| variable in line 1100:
>>>> -- snip --
>>>> 1097 fcntl(msg[1], F_SETFD, FD_CLOEXEC);
>>>> 1098 }
>>>> 1099 #endif
>>>> 1100 if (!(flags & SPAWN_FOREGROUND))
>>>> 1101 sigcritical(SIG_REG_EXEC|SIG_REG_PROC);
>>>> 1102 #if _lib_vfork
>>>> 1103 #if _lib_fork
>>>> 1104 if (nx.flags & SPAWN_VFORK)
>>>> -- snip --
>>>>
>>>>
>>>> 2nd hit is:
>>>> -- snip --
>>>> ==2461== Conditional jump or move depends on uninitialised value(s)
>>>> ==2461== at 0x4DC851: spawnvex (spawnvex.c:1100)
>>>> ==2461== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2461== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2461== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2461== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2461== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2461== by 0x40F0D5: exfile (main.c:588)
>>>> ==2461== by 0x40E29A: sh_main (main.c:360)
>>>> ==2461== by 0x40D450: main (pmain.c:45)
>>>> ==2461== Uninitialised value was created by a stack allocation
>>>> ==2461== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> -- snip --
>>>> ... again it seems to be the |flags| variable in line 1118:
>>>> -- snip --
>>>> 1117 {
>>>> 1118 if (!(flags & SPAWN_FOREGROUND))
>>>> 1119 sigcritical(0);
>>>> 1120 if (vex && (n = spawnvex_apply(vex, 0,
>>>> SPAWN_FRAME|SPAWN_NOCALL)))
>>>> 1121 errno = n;
>>>> -- snip --
>>>>
>>>>
>>>> 3rd (and last) hit is this one:
>>>> -- snip --
>>>> ==2461== Conditional jump or move depends on uninitialised value(s)
>>>> ==2461== at 0x4DCC77: spawnvex (spawnvex.c:1193)
>>>> ==2461== by 0x4653BF: _spawnveg (path.c:151)
>>>> ==2461== by 0x46895F: path_spawn (path.c:1228)
>>>> ==2461== by 0x480B36: sh_ntfork (xec.c:3824)
>>>> ==2461== by 0x479F01: sh_exec (xec.c:1675)
>>>> ==2461== by 0x47BC66: sh_exec (xec.c:2200)
>>>> ==2461== by 0x40F0D5: exfile (main.c:588)
>>>> ==2461== by 0x40E29A: sh_main (main.c:360)
>>>> ==2461== by 0x40D450: main (pmain.c:45)
>>>> ==2461== Uninitialised value was created by a stack allocation
>>>> ==2461== at 0x4DC6AE: spawnvex (spawnvex.c:793)
>>>> ==2461==
>>>> -- snip --
>>>> ... which relates to this code in line 1193:
>>>> -- snip --
>>>> 1192 }
>>>> 1193 if (!(flags & SPAWN_FOREGROUND))
>>>> 1194 sigcritical(0);
>>>> 1195 if (pid != -1 && vex)
>>>> -- snip --
>>>>
>>>> ... short summary: It's the |flags| variable which is uninitalised in
>>>> some usage cases.
>>>>
>>>> The frustrating part is that the --track-origins=yes option of
>>>> valgrind points to line 793:
>>>> -- snip --
>>>> 791 pid_t
>>>> 792 spawnvex(const char* path, char* const argv[], char* const
>>>> envv[], Spawnvex_t* vex)
>>>> 793 {
>>>> 794
>>>> -- snip --
>>>> This is the beginning of the function, IMO useless and frustrating
>>>> because the binary was explicitly created with -g -ggdb and optimiser
>>>> disabled.
>>>
>>> ping! ... is there a patch for the valgrind hits yet (well, I can
>>> "silence" the warnings via initalising the |flags| variable myself...
>>> but I'm not 100% sure whether this is the correct "fix") ?
>>
>> Erm... the issue is still present in ast-ksh.2013-03-18 and spamming
>> my valgrind logs... ;-((
>
> ast-ksh.2013-04-02 still has the same problem... ;-(((((((((((((
> ... the only issue which is "open" is whether initalising the |flags|
> variable (the "offender" causing the valgrind hits) at declaration
> time is the correct way... or not...
Here is the _workaround_ I'm using for ast-ksh.2013-05-03 ... I don't
know whether this is the _correct_ fix or not:
-- snip --
--- ./src/lib/libast/misc/spawnvex.c 2013-05-06 14:16:35.057550745 +0200
+++ ./src/lib/libast/misc/spawnvex.c 2013-05-06 14:17:25.400515058 +0200
@@ -793,7 +793,7 @@
{
int i;
int op;
- unsigned int flags;
+ unsigned int flags = 0U;
pid_t pid;
#if _lib_posix_spawn
int arg;
-- snip --
Glenn... can you please *VERIFY* whether this is the right fix (or not) ?
----
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
