Re: slapd dumping core with today's current.

2002-09-19 Thread Daniel Eischen

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 machine/reg.h
@@ -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.

2002-09-19 Thread Julian Elischer



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 machine/reg.h
 @@ -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.

2002-09-19 Thread Daniel Eischen

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.

2002-09-19 Thread Julian Elischer



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.

2002-09-19 Thread Daniel Eischen

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.

2002-09-19 Thread Edwin Culp

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.

2002-09-19 Thread Edwin Culp

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.

2002-09-19 Thread Bruce Evans

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.

2002-09-19 Thread Terry Lambert

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.

2002-09-19 Thread Daniel Eischen

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.

2002-09-19 Thread Terry Lambert

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.

2002-09-19 Thread Bruce Evans

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.

2002-09-18 Thread Joe Marcus Clarke

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



Re: slapd dumping core with today's current.

2002-09-18 Thread Julian Elischer

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.

2002-09-18 Thread Wesley Morgan

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