[Bug libc/612] New: makecontext broken on powerpc-linux

[Bug libc/612] New: makecontext broken on powerpc-linux

[olh at suse dot de]

the attached testcase loops forever in t1_func,setcontext calls on powerpc-linux
works ok in 64bit and on other architectures. glibc is sles9, 2.3.3 (20040412)

I havent figured out whats going on, need some more eyes looking on it.

-- 
           Summary: makecontext broken on powerpc-linux
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: olh at suse dot de
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: powerpc-linux
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-12-20 13:39 -------
Created an attachment (id=314)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=314&action=view)
makecontext1.c


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[aj at suse dot de]

------- Additional Comments From aj at suse dot de  2004-12-20 13:55 -------
Steve, this happens on PPC. Could you investigate, please? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aj at suse dot de
         AssignedTo|gotom at debian dot or dot  |sjmunroe at us dot ibm dot
                   |jp                          |com
             Status|NEW                         |ASSIGNED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[sjmunroe at us dot ibm dot com]

------- Additional Comments From sjmunroe at us dot ibm dot com  2004-12-20 21:13 -------
This is a bad testcase coupled with internal changes to PPC ucontext_t to 
maintian backward compat and accomadate VMX (Altivec) which requires stonger 
alignment then the base ucontext_t.

>From the IEEE Std 1003.1, 2004:

"The uc_link member is used to determine the context that shall be resumed 
when the context being modified by makecontext() returns. The application 
shall ensure that the uc_link member is initialized prior to the call to 
makecontext().

The swapcontext() function shall save the current context in the context 
structure pointed to by oucp and shall set the context to the context 
structure pointed to by ucp."

If they had used swapcontext as suggested to create the resume context (oucp) 
it would have worked. Instead they used getcontext then made a copy (via 
memcpy) to another ucontext_t for the resume context (oucp) pointed to by the 
uc_link. 

This works on some architecture but the PPC ucontext_t contains internal 
pointers. From ucontext.h:

     * Different versions of the kernel have stored the registers on
     * signal delivery at different offsets from the ucontext struct.
     * Programs should thus use the uc_mcontext.uc_regs pointer to
     * find where the registers are actually stored.  The registers
     * will be stored within the ucontext_t struct but not necessarily
     * at a fixed address.  As a side-effect, this lets us achieve
     * 16-byte alignment for the register storage space if the
     * Altivec registers are to be saved, without requiring 16-byte
     * alignment on the whole ucontext_t.

So when the 1st ucontext_t (ucp) was copied to the 2nd ucontext_t (oucp) the 
uc_mcontext.uc_regs pointer still pointed back into the 1st ucontext_t. Then 
makecontext(ucp, ...) modified (ucp) to dispatch t1_func() (which effectively 
changes both contexts!)

When t1_func() returns, it branches to code in makecontext which follows 
uc_link to get the address of the resume context. Makecontext then calls 
setcontext to dispatch the resume context. But as the resume context (oucp) 
contains a uc_regs that points back into the context modified by makecontext 
we have an infinite loop (makecontaxt resume, setcontext, t1_func, ...)

Net you can't JUST COPY ucontexts on PPC because of the uc_regs pointer. PPC64 
does not fail in this case becuase gregset_t is at a fixed offset. But VMX 
registers (if used) are accessed via an internal mcontext.v_regs pointer 
(allows for internal quadword allignment). So a PPC64 testcase programmed this 
way and dependent on VMX state might also fail. Net any platform where the 
ucontext_t contains internal pointers is likely to fail this testcase.

But if the testcase did not copy the ucontext and instead used swapcontext to 
create the resume context call platforms should work.



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-12-20 21:18 -------
Thanks Steve. Looks like this bug can be closed as invalid. 

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[sjmunroe at us dot ibm dot com]

------- Additional Comments From sjmunroe at us dot ibm dot com  2004-12-20 21:45 -------
Created an attachment (id=316)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=316&action=view)
Perfered makecontext test case

This makecontext1.c is correct for any platform including those with have
internal pointers in ucontext_t. 


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[sjmunroe at us dot ibm dot com]

------- Additional Comments From sjmunroe at us dot ibm dot com  2005-04-28 16:07 -------
This was test case problem. The ucontexts can not be copied, they must be
created by getcontext or swapcontext.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID


http://sources.redhat.com/bugzilla/show_bug.cgi?id=612

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/612] makecontext broken on powerpc-linux

[ovilewade9 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=612

ovile009988 <ovilewade9 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ovilewade9 at gmail dot com

--- Comment #7 from ovile009988 <ovilewade9 at gmail dot com> ---
Most of the users can getting here http://fixwindows10connections.com and see
function to need fix connections for bluetooth audio devices

-- 
You are receiving this mail because:
You are on the CC list for the bug.