[Bug 248717] New: bash-3.2.9 : Conditional jump or move depends on uninitialised value(s)
https://bugzilla.novell.com/show_bug.cgi?id=248717 Summary: bash-3.2.9 : Conditional jump or move depends on uninitialised value(s) Product: openSUSE 10.3 Version: Alpha 1 Platform: x86-64 OS/Version: SuSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: dcb314@hotmail.com QAContact: qa@suse.de I just tried to build package acct-6.3.5-719 with valgrind on Suse Linux 10.3 Alpha 1. I used command line valgrind -q --trace-children=yes rpmbuild -bc acct.spec The output contains checking for kitchen sink... You find a ring in the sink! ==15673== Conditional jump or move depends on uninitialised value(s) ==15673== at 0x4F6E6: array_to_assign (in /bin/bash) ==15673== by 0x4FA11: print_array_assignment (in /bin/bash) ==15673== by 0x34EFE: print_var_list (in /bin/bash) ==15673== by 0x64D6B: set_builtin (in /bin/bash) ==15673== by 0x2CCE7: (within /bin/bash) ==15673== by 0x2DD1B: (within /bin/bash) ==15673== by 0x2EAF6: execute_command_internal (in /bin/bash) ==15673== by 0x2FBE9: (within /bin/bash) ==15673== by 0x2EC2E: execute_command_internal (in /bin/bash) ==15673== by 0x3051D: (within /bin/bash) ==15673== by 0x2EC74: execute_command_internal (in /bin/bash) ==15673== by 0x5FA3A: parse_and_execute (in /bin/bash) So it seems that bash-3.2.9 is at fault. Suggest code rework. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 mhorvath@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |werner@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Minor Status|NEW |NEEDINFO Info Provider| |dcb314@hotmail.com ------- Comment #1 from werner@novell.com 2007-02-26 02:47 MST ------- What exactly does `So it seems that bash-3.2.9 is at fault' mean? Please be more precisely. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 dcb314@hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|dcb314@hotmail.com | ------- Comment #2 from dcb314@hotmail.com 2007-02-26 04:09 MST ------- (In reply to comment #1)
What exactly does `So it seems that bash-3.2.9 is at fault' mean? Please be more precisely.
It seems that during the execution of /bin/bash, it enters a routine called array_to_assign. array_to_assign is called from print_array_assignment During the execution of array_to_assign, a test is made of some data which has not been assigned to. So program /bin/bash, version 3.2.9 has a fault in it. It is doing an if () on something that hasn't been initialised. Suggest first step is to find out where in routine array_to_assign the fault is. Suggest build a version of bash with -g, and make sure it is at the top of the PATH. Then run the rpmbuild on acct.spec again. That should tell you the line of code in /bin/bash that is going wrong. If you need any more help, please let me know. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 ------- Comment #3 from werner@novell.com 2007-02-27 11:32 MST ------- IMHO valgrind is not correct, the char array indstr[] in array_to_assign() is filled by the function inttostr() and this function provides a pointer on the result. Nevertheless, not only the pointer `is' but also the array `indstr[]' is initialised after inttostr(): array_to_assign (a, quoted) ARRAY *a; int quoted; { char *result, *valstr, *is; char indstr[INT_STRLEN_BOUND(intmax_t) + 1]; ARRAY_ELEMENT *ae; int rsize, rlen, elen; if (a == 0 || array_empty (a)) return((char *)NULL); result = (char *)xmalloc (rsize = 128); result[0] = '('; rlen = 1; for (ae = element_forw(a->head); ae != a->head; ae = element_forw(ae)) { is = inttostr (element_index(ae), indstr, sizeof(indstr)); valstr = element_value (ae) ? sh_double_quote (element_value(ae)) : (char *)NULL; elen = STRLEN (indstr) + 8 + STRLEN (valstr); [...] replacing STRLEN(indstr) with STRLEN(is) removes the message but nevertheless the line is correct even without the change. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 ------- Comment #4 from dcb314@hotmail.com 2007-02-27 13:31 MST ------- (In reply to comment #3)
IMHO valgrind is not correct, the char array indstr[] in array_to_assign() is filled by the function inttostr() and this function provides a pointer on the result. Nevertheless, not only the pointer `is' but also the array `indstr[]' is initialised after inttostr():
I don't understand how this helps us find which line of code is going wrong. The report from valgrind says that a conditional move or jump uses an uninitialised value. How does that match up with your description ? BTW, in all the years I have been using valgrind, I have only ever found two faults in it, and it has found hundreds of bugs in other software. This makes me think that when it reports a fault, the odds are high, but not certain, that there really is a fault. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 ------- Comment #5 from werner@novell.com 2007-02-28 03:19 MST ------- Hmmm ... the valgrind report was ==20020== Conditional jump or move depends on uninitialised value(s) ==20020== at 0x4F6F6: array_to_assign (array.c:658) ==20020== by 0x4FA21: print_array_assignment (arrayfunc.c:555) ==20020== by 0x34EFE: print_var_list (variables.c:899) ==20020== by 0x64D7B: set_builtin (set.def:436) ==20020== by 0x2CCE7: execute_builtin (execute_cmd.c:3149) ==20020== by 0x2DD1B: execute_simple_command (execute_cmd.c:3535) ==20020== by 0x2EAF6: execute_command_internal (execute_cmd.c:672) ==20020== by 0x2FBE9: execute_in_subshell (execute_cmd.c:1354) ==20020== by 0x2EC2E: execute_command_internal (execute_cmd.c:544) ==20020== by 0x3051D: execute_connection (execute_cmd.c:1457) ==20020== by 0x2EC74: execute_command_internal (execute_cmd.c:824) ==20020== by 0x5FA4A: parse_and_execute (evalstring.c:275) ==20024== Conditional jump or move depends on uninitialised value(s) and line 658 witin array.c is elen = STRLEN (indstr) + 8 + STRLEN (valstr); and the only variable which is not assigned dirctly but with the help of inttostr() which is at least the function fmtulong() of the file lib/sh/fmtulong.c. AFAIS the return value of inttostr() is a pointer to the buffer which is filled within fmtulong(). I'll try to investigate more about this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 ------- Comment #6 from werner@novell.com 2007-02-28 03:45 MST ------- The valgrind output is caused by the shell command set for asking the bash about the set variables, AFAIK there are some arrays used by the bash its self, e.g. BASH_LINENO, BASH_SOURC, BASH_VERSINFO, DIRSTACK, GROUPS, and PIPESTATUS. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 ------- Comment #7 from werner@novell.com 2007-02-28 03:55 MST ------- The variable BASH_VERSINFO with the value BASH_VERSINFO=([0]="3" [1]="2" [2]="9" [3]="8" [4]="release" [5]="x86_64-suse-linux-gnu") seems the only shell array which cause the behaviour. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=248717 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #8 from werner@novell.com 2007-02-28 05:25 MST ------- OK found the reason, the function fmtulong() fills the buffer from the right to the left side, which is that the pointer depending on the numeric base (here the decimal base is used) fills the buffer with a string representing the numeric value. For small numbers the rest of the buffer, from start upto the pointer, remains untouched. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com