KSE/ia64 broken

[Marcel Moolenaar]

On Wed, Nov 19, 2003 at 04:27:51PM -0500, Daniel Eischen wrote:
> > > >
> > > The returned memory block from malloc() is being used by unknown code, I 
> > > don't know
> > > why it occurs, but if you waste a memory block by applying the following 
> > > patch for
> > > thr_alloc(), then things work:
> > 
> > The memory block is clobbered by a ucontext_t. This may be the result
> > of the kernel doing the upcall (though indirectly I would suspect).
> 
> Any more on this.  I haven't been able to find anything
> on our end.

Ok. More pieces of the puzzle. If I apply the attached patch (against
clean sources), I get the following:

itanium% ./foo.bad
XXX:_thr_alloc: thread=200000000008a000, tcb=2000000000085000
XXX:_thr_alloc: thread=2000000000090000, tcb=2000000000090000

The second _thr_alloc() is screwed up, in that malloc() returns
the same pointer twice. Hence thread->tcb points to thread itself
and we're clobbering our thread structure. Since thr_spinlock.c
affects the locking of malloc(), we may have a race condition.
Note that forcing an upcall (by adding a _thread_printf() in the
code stream) seems to fix it. Does the UTS call malloc when first
invoked?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net
-------------- next part --------------
Index: thr_kern.c
===================================================================
RCS file: /home/ncvs/src/lib/libpthread/thread/thr_kern.c,v
retrieving revision 1.102
diff -u -r1.102 thr_kern.c
--- thr_kern.c	9 Nov 2003 00:37:14 -0000	1.102
+++ thr_kern.c	21 Nov 2003 09:31:22 -0000
@@ -2443,6 +2443,8 @@
 			free(thread);
 			thread = NULL;
 		} else {
+			_thread_printf(1, "XXX:%s: thread=%p, tcb=%p\n",
+			    __func__, thread, thread->tcb);
 			/*
 			 * Initialize thread locking.
 			 * Lock initializing needs malloc, so don't