hi
I tried those libc_r test programs under about a month old CURRENT, and output
seems to be identical to yours (didn't try gdb on it but it gives same
guard_b segfaults and same programs fail)
here's the output:
Test static library:
--
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > On Mon, 1 Jul 2002, Julian Elischer wrote:
> >
> > > I think that gets us a LOT closer!
> > >
> > >
> > > Total tests 212, passed 212, failed 0
> > > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guar
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > I think that gets us a LOT closer!
> >
> >
> > Total tests 212, passed 212, failed 0
> > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
> > signal 11 (core dumped)
> > Jul 2
On Mon, 1 Jul 2002, Julian Elischer wrote:
> I think that gets us a LOT closer!
>
>
> Total tests 212, passed 212, failed 0
> ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
> signal 11 (core dumped)
> Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signa
I think that gets us a LOT closer!
Total tests 212, passed 212, failed 0
ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
signal 11 (core dumped)
Jul 2 01:52:52 ref4 kernel: pid 334 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 338 (g
> In <[EMAIL PROTECTED]>
> Julian Elischer <[EMAIL PROTECTED]> wrote:
JE> the question is:
JE> did you update both kernel and userland?
Yes. I always do update the whole world.
> I updated my current box about an hour ago, and got into trouble too.
And I backed kernel only of date=2
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > mutex_d (**hangs here**)
>
> This one takes quite a long time to run. Run it by hand and you'll
> see if it's really hanging or not.
you're not wrong!
it takes ages.. (still running in another window)
false al
On Mon, 1 Jul 2002, Julian Elischer wrote:
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> >
> > Someone can also try going into lib/libc_r/test and running the
> > tests in there, to see if even simple threaded programs are borken
> > or not.
> A
> cool
> I didn't know they are there!
>
>
turned out to be minor.. see other mail
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > I'm not sure. I would be interested in seeing any warnings from building
> > new libc_r. The only places I can think of are the queues (with the
> > QMD
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> Someone can also try going into lib/libc_r/test and running the
> tests in there, to see if even simple threaded programs are borken
> or not.
A
cool
I didn't know they are there!
heres what happens when it is run (After fixing typos)
make: don'
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> I'm not sure. I would be interested in seeing any warnings from building
> new libc_r. The only places I can think of are the queues (with the
> QMD debug defined, that would definitely cause problems), but that
> seems to have been ruled out also w
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> >
> > I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
> > 3 days ago (lib/libc_r/uthread/...). You can try reverting those
> > changes and go back to revisions 1.18 and 1.11 respec
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
> 3 days ago (lib/libc_r/uthread/...). You can try reverting those
> changes and go back to revisions 1.18 and 1.11 respectively.
It seems that you have been exhonorated..
I gue
oops,, sorry, you are right..
still it's being so confusing with people saying this and that, that it's
only now that I'm starting to believe that it's not the kernel
doing something nasty.
On Mon, 1 Jul 2002, Wesley Morgan wrote:
> I already tried that this morning, it had no effect ... Unl
I already tried that this morning, it had no effect ... Unless you would
like me to try an old kernel with it
On Mon, 1 Jul 2002, Julian Elischer wrote:
> can you try compiling a new libc_r with th efollowing change suggested by
> Dan Eischen:
>
> --begin quote:
>
> I also made changes to u
can you try compiling a new libc_r with th efollowing change suggested by
Dan Eischen:
--begin quote:
I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
3 days ago (lib/libc_r/uthread/...). You can try reverting those
changes and go back to revisions 1.18 and 1.11 respecti
Somehow this thread slipped into privmail.
Original Message
Subject: Re: Post-KSE disaster with libc_r
Date: Mon, 1 Jul 2002 14:23:23 -0700 (PDT)
From: Julian Elischer <[EMAIL PROTECTED]>
To: Michael Nottebrock <[EMAIL PROTECTED]>
> [Applied 'thediff
Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624,
still crashes all threaded systems. Same behavior on a 20020620 kernel.
> I don't change any of those.
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>>
>> I'd suspect that it is something to do with the layout of
>> the fpreg
On Mon, 1 Jul 2002, Julian Elischer wrote:
> I don't change any of those.
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
> >
> > I'd suspect that it is something to do with the layout of
> > the fpregs, mcontext or something like that. Libc_r mucks
> > about in jmp_buf (userland) and ucontext/mc
I don't change any of those.
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I'd suspect that it is something to do with the layout of
> the fpregs, mcontext or something like that. Libc_r mucks
> about in jmp_buf (userland) and ucontext/mcontext, so anything
> that changed those would cause prob
I have some debug stuff added for TAILQs
theoretically it should be defined out but
I don't trust theory :-)
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > is there any chance you can try compile a new libc_r but with old versions
> > of proc.h and
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
>
> > On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > > the question is:
> > > did you update both kernel and userland?
> >
> > This bug is not related to in-kernel KSE code (but, mayb
On Mon, 1 Jul 2002, Julian Elischer wrote:
> is there any chance you can try compile a new libc_r but with old versions
> of proc.h and queue.h in the system?
What changed in queue.h? We do have some macros defined for presetting
queue.h *_HEAD's.
--
Dan Eischen
To Unsubscribe: send mail to
is there any chance you can try compile a new libc_r but with old versions
of proc.h and queue.h in the system?
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kernel and userland?
>
> Th
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kernel and userland?
>
> This bug is not related to in-kernel KSE code (but, maybe related to
> header files compiled in). I got it even wi
Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
>
>>the question is:
>>did you update both kernel and userland?
>
>
> This bug is not related to in-kernel KSE code (but, maybe related to
> header files compiled in). I got it even with updated userland a
On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> the question is:
> did you update both kernel and userland?
This bug is not related to in-kernel KSE code (but, maybe related to
header files compiled in). I got it even with updated userland and old
pre-KSE kernel (with both update
the question is:
did you update both kernel and userland?
On Mon, 1 Jul 2002, NAKAJI Hiroyuki wrote:
> > In <[EMAIL PROTECTED]>
> > Marc Recht <[EMAIL PROTECTED]> wrote:
>
> > Can someone please check out a libc_r tree as of 3 days ago
> > and try that...
> >
> > There was a commit i
Ktracing with context switches look the same as before
Stepping into libc_r leads me on a merry chase through what appears to be
normal execution, until somewhere in uthread_sig.c about line 552...
(gdb) r
Starting program: /usr/local/bin/kdeinit
Breakpoint 1 at 0x28e839f6: file
/usr/src/lib/
> MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a
> MR> post-KSE kernel (30.06.) and I've none of the described problems.
> MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem.
>
> I updated my current box about an hour ago, and got into trouble too.
But
> In <[EMAIL PROTECTED]>
> Marc Recht <[EMAIL PROTECTED]> wrote:
> Can someone please check out a libc_r tree as of 3 days ago
> and try that...
>
> There was a commit in libc_r/uthreads 2 days ago that might be relevant.
> failing that, can someone try newly compiled utilities on an
> Can someone please check out a libc_r tree as of 3 days ago
> and try that...
>
> There was a commit in libc_r/uthreads 2 days ago that might be relevant.
> failing that, can someone try newly compiled utilities on an older pre-KSE
> kernel?
>
> We need to eliminate one of these two changes...
On Mon, 1 Jul 2002, Wesley Morgan wrote:
>
> Both the kdeinit and a child it forks are dying... Setting a breakpoint of
> fork() in the binary shows:
>
>
> Breakpoint 1, 0x28eda7d4 in fork () from /usr/lib/libc.so.5
> (gdb) bt
> #0 0x28eda7d4 in fork () from /usr/lib/libc.so.5
> #1 0x28e83a
On Mon, Jul 01, 2002 at 02:59:09AM -0400, Wesley Morgan wrote:
> 2723 kdeinit CALL gettimeofday(0x28e94ab8,0)
> 2723 kdeinit RET gettimeofday 0
> 2723 kdeinit CALL wait4(0x,0,0x1,0)
> 2723 kdeinit RET wait4 2724/0xaa4
> 2723 kdeinit CALL poll(0x8059000,0x1,0)
> 2723
Reverting to:
uthread_sigpending.c 1.8
uthread_sigsuspend.c 1.11
Makefile.inc 1.32
Has no effect. As far as I can tell theres no more changes...
Looking at some ktrace / gdb output shows the funny business starting
right after kdeinit tries to fork into something else:
2723 kdeinit CALL ge
Can someone please check out a libc_r tree as of 3 days ago
and try that...
There was a commit in libc_r/uthreads 2 days ago that might be relevant.
failing that, can someone try newly compiled utilities on an older pre-KSE
kernel?
We need to eliminate one of these two changes...
I think it's l
36 matches
Mail list logo
