Date: Tue, 26 Nov 2002 16:39:42 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Marc Recht <marc@informatik.uni-bremen.de> Cc: Daniel Eischen <eischen@vigrid.com>, freebsd-current@FreeBSD.ORG Subject: Re: PATCH - changing libc_r to use *context() Message-ID: <Pine.GSO.4.10.10211261626160.15580-100000@pcnet1.pcnet.com> In-Reply-To: <16330000.1038336929@leeloo.intern.geht.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Nov 2002, Marc Recht wrote:
> > I'd like some feedback on whether some heavy threaded apps (GNOME,
> > OpenOffice, Java, etc) have any problems with this patch before
> > asking re@ for commit permission. BTW, it also needs testing on
> > alpha.
> I tried it on i386 (athon-xp) and every app I've tried stalled/locked or
> crashed right away. Mozilla gives me:
> The program '<unknown>' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadValue (integer parameter out of range for operation)'.
> (Details: serial 4773 error_code 2 request_code 53 minor_code 0)
> (Note to programmers: normally, X errors are reported asynchronously;
> that is, you will receive the error a while after causing it.
> To debug your program, run it with the --sync command line
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error() function.)
Damn, I think I found a problem. Perhaps it might be what's
causing your problem. Do you have I686_CPU defined in
your kernel? If so can you either try it with a kernel
without I686_CPU or with CPU_DISABLE_SSE?
The kernel doesn't align the FPU registers (context) properly.
Actually, neither does anything in userland because the
machine contexts lack align directives.
You can also try modifying the patched uthread_kern.c,
function _thread_kern_sched(). There's a section about
halfway down that looks something like this:
/*
* Return to the interrupted context. We are careful
* not to use the context saved in the thread because
* we may have been interrupted by another signal which
* would have destroyed it. This context is saved by
* the kernel on the thread's stack so it is safe from
* nested signals.
*/
ucp->uc_sigmask = _process_sigmask;
THR_SETCONTEXT(ucp);
PANIC("Resume from setcontext in _thread_kern_sched");
}
else {
do {
Change the THR_SETCONTEXT(ucp) to sigreturn(ucp).
--
Dan Eischen
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10211261626160.15580-100000>