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.