cvs commit: src/lib/libkse/thread thr_kern.c

[Arno J. Klaassen]

Hello,


Daniel Eischen <deischen at freebsd.org> writes:

> On Sat, 1 Dec 2007, Arno J. Klaassen wrote:
> 
> > Daniel Eischen <deischen at freebsd.org> writes:
> >
> >>> Arno J. Klaassen wrote:
> >>>
> >>> [ ... ]
> >>> That gives :
> >>>
> >>> #0  0x000000080075d151 in _pthread_sigmask (how=3, set=0x813cc6e10, oset=0x0)
> >>>    at /files/bsd/src7/lib/libkse/thread/thr_sigmask.c:52
> >>> #1  0x000000080075d103 in _sigprocmask (how=3, set=0x813cc6e10, oset=0x0)
> >>>    at /files/bsd/src7/lib/libkse/thread/thr_sigprocmask.c:49
> >>> #2  0x000000080076c423 in _kse_single_thread (curthread=0x813cc6c00)
> >>>    at /files/bsd/src7/lib/libkse/thread/thr_kern.c:361
> >>> #3  0x0000000800758f29 in _fork ()
> >>>    at /files/bsd/src7/lib/libkse/thread/thr_fork.c:101
> >>> #4  0x0000000801e43158 in jdk_fork_wrapper ()
> >>>    at ../../../src/solaris/native/java/lang/UNIXProcess_md.c:437
> >>>
> >>> Hope this is better
> >>
> >> Yes, this would seem to be a kernel problem, as _get_curthread()
> >> seems to be returning garbage.
> >
> > (gdb) p curthread
> > $1 = (struct pthread *) 0x0
> >
> >
> >> This is a libkse MD function,
> >> that relies on %gs (for i386/amd64) to point to something
> >> that was initialized in the parent.
> >>
> >> Julian, David, got any ideas?
> >
> > I can publish ti full java_g.core if helpful.
> 
> You could of course try this hack to work-around the problem:
> 
> Index: thr_kern.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libkse/thread/thr_kern.c,v
> retrieving revision 1.127
> diff -u -r1.127 thr_kern.c
> --- thr_kern.c	30 Nov 2007 17:16:14 -0000	1.127
> +++ thr_kern.c	1 Dec 2007 23:23:42 -0000
> @@ -361,6 +361,13 @@
>   	curthread->kse->k_kcb->kcb_kmbx.km_curthread = NULL;
>   	curthread->attr.flags |= PTHREAD_SCOPE_SYSTEM;
> 
> +	/*
> +	 * This shouldn't be necessary.  It sometimes gets corrupted
> +	 * after a fork() in SMP.
> +	 */
> +	_kcb_set(curthread->kse->k_kcb);
> +	_tcb_set(curthread->kse->k_kcb, curthread->tcb);
> +
>   	/* After a fork(), there child should have no pending signals. */
>   	sigemptyset(&curthread->sigpend);
> 
> 

Yes, this works. Thanx!
Is this safe to apply to releng_6 as well?

For info, the attached patch, which partially reverts mfc of rev 1.286
of kern_fork.c, seems to work as well (without the above patch to be clear),
or at least makes it much harder to trigger (just reading the comments it
seems just to give one extra second to copy user space before accessing it
which seems enough in my setup).

Hope this helps to track down the real culprit (I do have problems
with libthr and java as well on 2x2 SMP I do not have elsewhere, but
they are much harder to trigger and I have not been able yet to
find a simple test-setup which reproduces them easily and reproductable).

Thank you very much for your help.

Best, Arno



-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread_single_rev.patch
Type: text/x-patch
Size: 1812 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-java/attachments/20071202/a58f791c/thread_single_rev.bin