Re: Easy Guide / new tarball
Date: Sun, 17 Oct 1999 15:36:32 -0400 (EDT)
From: John Tobey <spam@john-edwin-tobey.org>
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> > Apart from that things are working fine.
>
> Thanks for testing!
Well thanks for tarring! but I may have spoken too soon... though
this probably has nothing to do with the tarball per se. I'm trying
to build perl with debugging support. After maybe an hour of
compiling, the foreground process freezes. It does not generally
happen in the same place. At that point, root can run
# ps
in another window and see its own processes, but
# ps A
(which would show the crashed process) does nothing. It is
interruptible by ^C. Then the system gradually becomes unusable. At
one point I would run
One of the things `ps' does is sending a message to what we call the
msg port of a process. If a process hangs, it will not respond and
`ps' hangs on the message receive operation. It will eventually time
out but that will take a pretty long time. You can use the -M option
to prevent `ps' from using the message port.
$ gdb
and it would background itself with (if I remember right) a SEGV. But
now, having recently booted, my gdb processes behave like normal.
That shouldn't happen. Probably a bug in `gdb' that's trigerred by
the somewhat hosed state your system was in at that stage.
I was getting into the habit of booting, fixing the build partition,
restarting make, waiting for the crash, and rebooting, but then the
crash happened once during the shutdown sequence, and I became
discouraged. :-( Now it's happened twice in a row on POSIX.c (the
biggest C file), so I'm not too hopeful of finishing this.
The Hurd will eventually crash on large compiles. How large the
compile has to be to make this happen depends on factors such as the
amount of memory and swap space you have. I have been able to compile
Perl without problems on my Hurd (which is based on a snapshot from
july or so with some bug fixes) in 32 MB RAM and 128 MB swap.
Is this normal Hurd behavior these days? I would try to debug it, but
I don't think my chances of success are worth the effort of building a
debuggable Hurd at the rate I'm going. When's that hurd-dbg coming,
Marcus? ;-)
It shouldn't be normal.
btw, I saw a failed assertion in libdiskfs about an unexpected fault,
and just now I saw 50 or so like this:
memory_object_data_request(0x0, 0x0, 0x17000, 0x1000, 0x1) failed, 268435459
^^^^^^^ only this varies
Can you provide the location of the failed assertion?
The m_o_d_r message probably means that your filesystem died.
Mark
Reply to: