https://bugzilla.novell.com/show_bug.cgi?id=431661 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |werner@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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User bw@inside-security.de added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c2 Boris Wesslowski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|bw@inside-security.de | --- Comment #2 from Boris Wesslowski 2008-10-06 03:38:31 MDT --- I tested this on i386 and x86_64 and found the problem on both. uname -a Linux zap 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64 x86_64 x86_64 GNU/Linux locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User bw@inside-security.de added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c4 --- Comment #4 from Boris Wesslowski 2008-10-06 07:56:14 MDT --- Thanks for verifying the problem... Some other environment issue seems improbable since the tcsh binary from 10.3 x86_64 (compiled with GCC 4.2.1) does not show the problem when run on 11.0 x86_64 (where tcsh was compiled with GCC 4.3.1 20080507 prerelease). This problem with tcsh is not really critical and is rather simple to work around in several ways, but if it is caused by a bug in gcc the exact conditions for this bug should at least be known, some other occurrence (although maybe hard to find) may be critical... So, should this ticket be assigned to the maintainer(s) of the gcc package? Or should I try to verify it and open a "gcc miscompiles tcsh on 11.0" ticket? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c6 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Dr. Werner Fink 2008-10-06 08:27:15 MDT --- I've submitted a tcsh with this patch to openSuSE 11.1 ... it could be an optimization problem with the gcc of 11.0 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c8 --- Comment #8 from Dr. Werner Fink 2008-10-08 06:32:14 MDT --- The code should be read as if (!l || ((c = TRM(*l)) != ' ' && c != '\t' && c != '\n')) break; the macro Strsave is mapped on the function Char * s_strsave(const Char *s) { Char *n; size_t size; if (s == NULL) s = STRNULL; size = (Strlen(s) + 1) * sizeof(*n); n = xmalloc(size); memcpy(n, s, size); return (n); } with Char STRNULL[] = { '\0' }; and typedef wchar_t Char; #define Strlen(a) wcslen(a) for the used wide character build of the tcsh. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c10 --- Comment #10 from Dr. Werner Fink 2008-10-09 04:02:12 MDT --- I've added this to avoid future problems with the gcc. My guess is: the gcc has removed the NULL pointer check in a function declared and defined in the tcsh source code (maybe named similar as a builtin of the gcc but with the attribute nonnull). To test this you may use `-O2 -fno-builtin'. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c12 --- Comment #12 from Dr. Werner Fink 2008-10-09 04:36:42 MDT --- You could try `-fno-delete-null-pointer-checks' instead `-fno-tree-pre' but the last one I've seen this problem, only the last option had helped whereas the first option seems to be more like a noop. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User bw@inside-security.de added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c14 --- Comment #14 from Boris Wesslowski 2008-10-13 07:05:03 MDT --- Analysis shows that after returning from dosource() the state of the program is still correct. Upon entering syntax() the linked list behind the paraml structure that contains the parts of the next command is already corrupted. The corruption happens below alias(), after lex() returns, at the end of asyn3(): The code that triggers it is: 1: p1->next->prev = alout.prev->prev; 2: alout.prev->prev->next = p1->next; 3: alout.next->prev = p1; 4: p1->next = alout.next; In the minimal case (which we get with the line break at the start of the alias) p1 and alout consist of two elements each which should make p1 stay the same as it was before this code. But what happens is that a link to alout is kept (of which the first element is local and the second is freed in asyn3()). This breaks the parser later. gcc -O1 compiles the code as: 1: mov 0x10(%r12),%rdx mov 0x8(%rsp),%rax mov 0x8(%rax),%rax mov %rax,0x8(%rdx) 2: mov 0x8(%rsp),%rax mov 0x8(%rax),%rax mov %rdx,0x10(%rax) 3: mov 0x10(%rsp),%rax mov %r12,0x8(%rax) 4: mov %rax,0x10(%r12) gcc -O1 -fstrict-aliasing -ftree-pre compiles it as 1: mov 0x8(%rsp),%rdx mov 0x10(%r12),%rcx mov 0x8(%rdx),%rax mov %rax,0x8(%rcx) 2: mov 0x8(%rdx),%rax mov %rcx,0x10(%rax) 3: mov %r12,0x8(%rsi) 4: mov %rsi,0x10(%r12) As far as I can see this is not functionally equivalent after step 2, gcc seems to have a reason to believe that alout.prev->prev->next could never point to the same as alout.next, which is not true. It is not clear what this reason could be, a simple testcase does not trigger the problem. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=431661 User bw@inside-security.de added comment https://bugzilla.novell.com/show_bug.cgi?id=431661#c16 --- Comment #16 from Boris Wesslowski 2008-10-13 07:35:22 MDT --- Sure, as described in this ticket: The problem happens with openSUSE 11.0 only, but there on i586 and x86_64 (tested on x86_64, on i586 at least tcsh shows the same symptoms), the openSUSE 11.0 compiler is "gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux)". -- 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.