KSE/ia64: NULL thread pointer in _thr_sig_add()

[Daniel Eischen]

On Sun, 10 Aug 2003, Marcel Moolenaar wrote:

> Gang,
> 
> There seems to be a bug in libkse where we dereference the thread
> pointer in situations where it's NULL. I suspect this bug is
> specific to platforms that have per-thread thread pointers. I
> have some rough gdb(1) support to help out with the analysis:

_thr_sig_add() does look at the current thread but it doesn't
dereference it.  I think it's OK for it to be null.  Is it
possible that _tp (which points to the tcb) isn't set?  So
that when you dereference it you get the error?  Is the
upcall somehow clearing _tp?

> The fault is given on the last instruction if the disassembly
> given above (the thread pointer is r13):
> 
> (gdb) info register r13
> r13            0x0      0
> (gdb) info register r14
> r14            0xffffffffffffffe0       -32

Right, that's what I was guessing.

> Q: Shouldn't we call _tcb_set() somewhere in the code stream to make
> sure we have a valid thread pointer?

Once its set, it should always be set, right?  The kernel doesn't
change it, right?  I think that's the idea anyways.  If you look at
the beginning of _thr_sched_multi(), we handle first time initialization:

	if ((curkse->k_flags & KF_INITIALIZED) == 0) {
		/* Setup this KSEs specific data. */
		_kcb_set(curkse->k_kcb);

		/* Set this before grabbing the context. */
		curkse->k_flags |= KF_INITIALIZED;
	}

That should set it up so that we always have TP set to something
(in this case, it's the fake tcb).  But from then on, we rely
on the kernel not to touch it.  Are you sure the kernel doesn't
destroy it somehow?

-- 
Dan Eischen