Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Terry Lambert wrote:
> Daniel Eischen wrote:
> > That's kind of the point of adding the fields that we did
> > (mc_len, mc_fpformat). They can be used to help validate
> > the contents and to allow extensions. We also have some
> > spare slots, but the last incarnation of ucontext_t also
> > had spare slots and it wasn't nearly enough for what we
> > now need.
>
> I was thinking more along the lines of:
>
> struct extend {
> struct extend *next; /* Next extension in list */
> int32_t id; /* extension ID */
> charcrap[1];/* extension specific data */
> };
>
> And then adding:
>
> struct extend *extensions;
>
> Yeah, if it's non-NULL, it means a linear list traversal to find
> relevent extensions, but that's better than non-working.
>
> String-to-id translation is a seperate function, and can also use
> a linear list traversal to find the string, get an ID back, and
> then subsequqnetly use the ID. Yeah, it's an extra contents
> dereference, but it's better than non-working.
Some of the extensions need to be understood by userland, so I think you
don't want it that complicated. Setting up userland pointers in the kernel
is hard enough without having to keep it backwards compatible. The kernel
would also have to worry about userland clobbering the pointers before it
follows them in sigreturn().
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
Daniel Eischen wrote:
> That's kind of the point of adding the fields that we did
> (mc_len, mc_fpformat). They can be used to help validate
> the contents and to allow extensions. We also have some
> spare slots, but the last incarnation of ucontext_t also
> had spare slots and it wasn't nearly enough for what we
> now need.
I was thinking more along the lines of:
struct extend {
struct extend *next; /* Next extension in list */
int32_t id; /* extension ID */
charcrap[1];/* extension specific data */
};
And then adding:
struct extend *extensions;
Yeah, if it's non-NULL, it means a linear list traversal to find
relevent extensions, but that's better than non-working.
String-to-id translation is a seperate function, and can also use
a linear list traversal to find the string, get an ID back, and
then subsequqnetly use the ID. Yeah, it's an extra contents
dereference, but it's better than non-working.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Terry Lambert wrote: > Bruce Evans wrote: > > Unfortunately, we didn't get expansion of the i386 mcontext_t to make > > room for SSE, into 4.0, and the problem has been mostly ignored since > > then. Looks like it is a large problem. > > Any chance of avoiding this in the future by adding an "extensible, > but known to be suboptimal if used" extension field, so that these > kind of changes can be made without having to change anything > important to the point of incompatability? > > That type of thing would let the problem be fixed in an ugly way, > but at least it would be fixed, without balancing things on a > knife's edge of incompatability vs. non-working code. That's kind of the point of adding the fields that we did (mc_len, mc_fpformat). They can be used to help validate the contents and to allow extensions. We also have some spare slots, but the last incarnation of ucontext_t also had spare slots and it wasn't nearly enough for what we now need. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
Bruce Evans wrote: > Unfortunately, we didn't get expansion of the i386 mcontext_t to make > room for SSE, into 4.0, and the problem has been mostly ignored since > then. Looks like it is a large problem. Any chance of avoiding this in the future by adding an "extensible, but known to be suboptimal if used" extension field, so that these kind of changes can be made without having to change anything important to the point of incompatability? That type of thing would let the problem be fixed in an ugly way, but at least it would be fixed, without balancing things on a knife's edge of incompatability vs. non-working code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote: > On Thu, 19 Sep 2002, Julian Elischer wrote: > > On Thu, 19 Sep 2002, Daniel Eischen wrote: > > > > Ok so I reconnected the libc_r and fixed it to compile. > > > > I'm a littel uncomfortable because the new kernel behaviour means that > > 4.x statically compiled threaded binaries will not work right because > > we've changed the kernel ABI in an incompatible way.. > > We need to discuss this carefully when mini gets back to see if there is > > a way out.. > > I brought this up with bde before. My suggestion was to create > another sigreturn(), so we'd have osigreturn(), osigreturn2(), > and [new] sigreturn(). He didn't like this. I think we'd need > another sendsig() too. > > When mini adds setcontext() as a system call, this can make > sigreturn() obsolete. The signal trampoline can call setcontext() > instead of sigreturn() and sigreturn() can handle the old > format... We still need a different sendsig() though. Unfortunately, we didn't get expansion of the i386 mcontext_t to make room for SSE, into 4.0, and the problem has been mostly ignored since then. Looks like it is a large problem. The things we might have to do to keep compatibile with old applications are similar to the things that might be necessary for efficiency. sendsig() and sigreturn() spend a lot of time copying out and in large amounts of state that are never really used, especially by old applications that cannot know about the new state. Optimizations would involve not copying it all, and compatibilty would also involve not even leaving space for copying it all. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
Quoting Wesley Morgan <[EMAIL PROTECTED]>: | Boot from a kernel from a day or two ago and you should be fine. Unless | you build every day, your kernel.old/kernel should be in agreement with | libc_r I do build everyday and Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
Quoting Julian Elischer <[EMAIL PROTECTED]>: | threads is broken right now.. | due to a miscommunicatin,. the kernel and the threads library have | a disagreement regarding something.. | Unfortunatly the person to slap up over this is offline for aday or | so.. | please be patient for a day or so (we hope). No problem. Thanks a lot, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Julian Elischer wrote: > On Thu, 19 Sep 2002, Daniel Eischen wrote: > > Ok so I reconnected the libc_r and fixed it to compile. > > I'm a littel uncomfortable because the new kernel behaviour means that > 4.x statically compiled threaded binaries will not work right because > we've changed the kernel ABI in an incompatible way.. > We need to discuss this carefully when mini gets back to see if there is > a way out.. I brought this up with bde before. My suggestion was to create another sigreturn(), so we'd have osigreturn(), osigreturn2(), and [new] sigreturn(). He didn't like this. I think we'd need another sendsig() too. When mini adds setcontext() as a system call, this can make sigreturn() obsolete. The signal trampoline can call setcontext() instead of sigreturn() and sigreturn() can handle the old format... We still need a different sendsig() though. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote: Ok so I reconnected the libc_r and fixed it to compile. I'm a littel uncomfortable because the new kernel behaviour means that 4.x statically compiled threaded binaries will not work right because we've changed the kernel ABI in an incompatible way.. We need to discuss this carefully when mini gets back to see if there is a way out.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Julian Elischer wrote: > On Thu, 19 Sep 2002, Daniel Eischen wrote: > > > On Wed, 18 Sep 2002, Julian Elischer wrote: > > > > > threads is broken right now.. > > > due to a miscommunicatin,. the kernel and the threads library have > > > a disagreement regarding something.. > > > Unfortunatly the person to slap up over this is offline for aday or > > > so.. > > > please be patient for a day or so (we hope). > > > > I think it's because libc_r has been disconnected from the > > build: > > > > revision 1.143 > > date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1 > > Add i386 to the list of architectures that libc_r is broken on. This > > effectively removes pppctl from the build for now. It only compiles on > > alpha now (now ironic). > > > > And the i386 mcontext_t is now bigger because we account for the > > newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's > > that were smaller and manually save and restore FP state into > > areas of ucontext_t which mc_len and mc_fpformat now occupy. > > so does that code still exist? Because libc_r is still disconnected from the build, the older library is still left in place. This library messes with a ucontext (a sigcontext sent to userland from the kernel via a signal handler) that corrupts it (invalidates it) so that when it returns to the kernel from the signal frame (sigreturn), the kernel returns an error or doesn't restore the FP state (see sigreturn() in machdep.c; it calls set_fpcontext() which checks mc_fpformat). A freshly built libc_r with the patches I sent should not mess with any FP state in a ucontext and should avoid the problem. It doesn't have to save and restore the FP state anymore because the i386 code now correctly saves and restores the FP state when sending a signal. Or at least that's the intent of the new code. > > The kernel uses these to validate a context and returns an > > error if these fields aren't valid. > > so, we need to change the kernel too right? No, the kernel is doing the right thing; it's just that the old userland library isn't yet seeing a ucontext in the same way the kernel is. > > The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC > > in libc_r/uthread/uthread_kern.c. And to also hook libc_r back > > into the build (src/lib/Makefile). > > If we remove the calls, is the original code still present? > or did that get removed? Removing the calls should make it build again, and hooking it back into the build/install process will update the old libc_r so that it works with a new kernel. Threads won't work totally right with the new library and an old kernel because the FP state won't be saved/restored by either the kernel or the library. Is this what you meant? -- Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote:
> On Wed, 18 Sep 2002, Julian Elischer wrote:
>
> > threads is broken right now..
> > due to a miscommunicatin,. the kernel and the threads library have
> > a disagreement regarding something..
> > Unfortunatly the person to slap up over this is offline for aday or
> > so..
> > please be patient for a day or so (we hope).
>
> I think it's because libc_r has been disconnected from the
> build:
>
> revision 1.143
> date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1
> Add i386 to the list of architectures that libc_r is broken on. This
> effectively removes pppctl from the build for now. It only compiles on
> alpha now (now ironic).
>
> And the i386 mcontext_t is now bigger because we account for the
> newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's
> that were smaller and manually save and restore FP state into
> areas of ucontext_t which mc_len and mc_fpformat now occupy.
so does that code still exist?
> The kernel uses these to validate a context and returns an
> error if these fields aren't valid.
so, we need to change the kernel too right?
>
> The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC
> in libc_r/uthread/uthread_kern.c. And to also hook libc_r back
> into the build (src/lib/Makefile).
If we remove the calls, is the original code still present?
or did that get removed?
>
> Libc_r patch included (which my mailer will probably mangle).
>
> --
> Dan Eischen
>
> Index: pthread_private.h
> ===
> RCS file: /opt/d/CVS/src/lib/libc_r/uthread/pthread_private.h,v
> retrieving revision 1.73
> diff -u -r1.73 pthread_private.h
> --- pthread_private.h 29 Aug 2002 23:06:06 - 1.73
> +++ pthread_private.h 19 Sep 2002 06:53:57 -
> @@ -75,16 +75,6 @@
> #define SET_STACK_JB(jb, stk) (jb)[0]._jb[2] = (int)(stk)
> #define SET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[2] = (int)(stk)
> #define SET_STACK_UC(ucp, stk) (ucp)->uc_mcontext.mc_esp = (int)(stk)
> -#define FP_SAVE_UC(ucp) do {\
> - char*fdata; \
> - fdata = (char *) (ucp)->uc_mcontext.mc_fpregs; \
> - __asm__("fnsave %0": :"m"(*fdata)); \
> -} while (0)
> -#define FP_RESTORE_UC(ucp) do {\
> - char*fdata; \
> - fdata = (char *) (ucp)->uc_mcontext.mc_fpregs; \
> - __asm__("frstor %0": :"m"(*fdata)); \
> -} while (0)
> #define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra)
> #elifdefined(__alpha__)
> #include
> @@ -94,8 +84,6 @@
> #define SET_STACK_JB(jb, stk) (jb)[0]._jb[R_SP + 4] = (long)(stk)
> #define SET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[R_SP + 4] = (long)(stk)
> #define SET_STACK_UC(ucp, stk) (ucp)->uc_mcontext.mc_regs[R_SP] = (unsigned
>long)(stk)
> -#define FP_SAVE_UC(ucp)
> -#define FP_RESTORE_UC(ucp)
> #define SET_RETURN_ADDR_JB(jb, ra) do { \
> (jb)[0]._jb[2] = (long)(ra);\
> (jb)[0]._jb[R_RA + 4] = (long)(ra); \
> Index: uthread_kern.c
> ===
> RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v
> retrieving revision 1.42
> diff -u -r1.42 uthread_kern.c
> --- uthread_kern.c29 Aug 2002 00:44:11 - 1.42
> +++ uthread_kern.c19 Sep 2002 06:53:55 -
> @@ -113,8 +113,6 @@
>
> /* Check if this function was called from the signal handler: */
> if (ucp != NULL) {
> - /* XXX - Save FP registers? */
> - FP_SAVE_UC(ucp);
> called_from_handler = 1;
> DBG_MSG("Entering scheduler due to signal\n");
> }
> @@ -156,9 +154,6 @@
> if (ucp == NULL)
> return;
> else {
> - /* XXX - Restore FP registers? */
> - FP_RESTORE_UC(ucp);
> -
> /*
>* Set the process signal mask in the context; it
>* could have changed by the handler.
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Wed, 18 Sep 2002, Julian Elischer wrote:
> threads is broken right now..
> due to a miscommunicatin,. the kernel and the threads library have
> a disagreement regarding something..
> Unfortunatly the person to slap up over this is offline for aday or
> so..
> please be patient for a day or so (we hope).
I think it's because libc_r has been disconnected from the
build:
revision 1.143
date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1
Add i386 to the list of architectures that libc_r is broken on. This
effectively removes pppctl from the build for now. It only compiles on
alpha now (now ironic).
And the i386 mcontext_t is now bigger because we account for the
newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's
that were smaller and manually save and restore FP state into
areas of ucontext_t which mc_len and mc_fpformat now occupy.
The kernel uses these to validate a context and returns an
error if these fields aren't valid.
The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC
in libc_r/uthread/uthread_kern.c. And to also hook libc_r back
into the build (src/lib/Makefile).
Libc_r patch included (which my mailer will probably mangle).
--
Dan Eischen
Index: pthread_private.h
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/pthread_private.h,v
retrieving revision 1.73
diff -u -r1.73 pthread_private.h
--- pthread_private.h 29 Aug 2002 23:06:06 - 1.73
+++ pthread_private.h 19 Sep 2002 06:53:57 -
@@ -75,16 +75,6 @@
#defineSET_STACK_JB(jb, stk) (jb)[0]._jb[2] = (int)(stk)
#defineSET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[2] = (int)(stk)
#defineSET_STACK_UC(ucp, stk) (ucp)->uc_mcontext.mc_esp = (int)(stk)
-#defineFP_SAVE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)->uc_mcontext.mc_fpregs; \
- __asm__("fnsave %0": :"m"(*fdata)); \
-} while (0)
-#defineFP_RESTORE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)->uc_mcontext.mc_fpregs; \
- __asm__("frstor %0": :"m"(*fdata)); \
-} while (0)
#define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra)
#elif defined(__alpha__)
#include
@@ -94,8 +84,6 @@
#defineSET_STACK_JB(jb, stk) (jb)[0]._jb[R_SP + 4] = (long)(stk)
#defineSET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[R_SP + 4] = (long)(stk)
#defineSET_STACK_UC(ucp, stk) (ucp)->uc_mcontext.mc_regs[R_SP] = (unsigned
long)(stk)
-#defineFP_SAVE_UC(ucp)
-#defineFP_RESTORE_UC(ucp)
#define SET_RETURN_ADDR_JB(jb, ra) do {\
(jb)[0]._jb[2] = (long)(ra);\
(jb)[0]._jb[R_RA + 4] = (long)(ra); \
Index: uthread_kern.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.42
diff -u -r1.42 uthread_kern.c
--- uthread_kern.c 29 Aug 2002 00:44:11 - 1.42
+++ uthread_kern.c 19 Sep 2002 06:53:55 -
@@ -113,8 +113,6 @@
/* Check if this function was called from the signal handler: */
if (ucp != NULL) {
- /* XXX - Save FP registers? */
- FP_SAVE_UC(ucp);
called_from_handler = 1;
DBG_MSG("Entering scheduler due to signal\n");
}
@@ -156,9 +154,6 @@
if (ucp == NULL)
return;
else {
- /* XXX - Restore FP registers? */
- FP_RESTORE_UC(ucp);
-
/*
* Set the process signal mask in the context; it
* could have changed by the handler.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
Boot from a kernel from a day or two ago and you should be fine. Unless you build every day, your kernel.old/kernel should be in agreement with libc_r On Wed, 18 Sep 2002, Julian Elischer wrote: > threads is broken right now.. > due to a miscommunicatin,. the kernel and the threads library have > a disagreement regarding something.. > Unfortunatly the person to slap up over this is offline for aday or > so.. > please be patient for a day or so (we hope). > > > On Wed, 18 Sep 2002, Edwin Culp wrote: > > > I just realized that slapd dumps core with: > > > > Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file > > /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) > > Abort (core dumped) > > > > I have recompiled openldap and db3 but it didn't help. Any suggestions > > would be appreciated. > > > > I also get the same error with mozilla but I see that has already been > > reported. > > > > Thanks, > > > > ed > > > > > > > > -- > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
threads is broken right now.. due to a miscommunicatin,. the kernel and the threads library have a disagreement regarding something.. Unfortunatly the person to slap up over this is offline for aday or so.. please be patient for a day or so (we hope). On Wed, 18 Sep 2002, Edwin Culp wrote: > I just realized that slapd dumps core with: > > Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file > /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) > Abort (core dumped) > > I have recompiled openldap and db3 but it didn't help. Any suggestions > would be appreciated. > > I also get the same error with mozilla but I see that has already been > reported. > > Thanks, > > ed > > > > -- > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slapd dumping core with today's current.
On Thu, 2002-09-19 at 00:32, Edwin Culp wrote: > I just realized that slapd dumps core with: > > Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file > /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) > Abort (core dumped) > > I have recompiled openldap and db3 but it didn't help. Any suggestions > would be appreciated. > > I also get the same error with mozilla but I see that has already been > reported. It's the same problem. libc_r is in a bad state. The KSE people are aware. I think Julian is looking into it. Joe > > Thanks, > > ed > > > > -- > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
