davidxu at freebsd.org
Fri Nov 21 04:22:23 PST 2003
Marcel Moolenaar wrote:
>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
>>>>why it occurs, but if you waste a memory block by applying the following
>>>>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:
>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.
I saw the same result.
>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
No, we never call malloc in such case. I suspect we do not
fully restore thread's context. In kernel, I pass zero as third
parameter to get_mcontext(), is it enough for ia64 ?
More information about the freebsd-threads