Steel Bank Common Lisp

On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote:
> Yes, but as "compensation" it seems that it doesn't work on BSD,
> especially OpenBSD, anymore.

(I didn't realize there was another OpenBSD user out there! Welcome!)
 
> I have 0.6.11.41 running, and newer sources from the CVS fail to compile
> with that host, especially in the C runtime system.
> 
> There are problems that the source uses the names "st_mtime" ...
> in an own structure to map the OS specific struct stat to a common
> structure, however, on OpenBSD, struct stat contains:
> 
> 	...
>         struct  timespec st_atimespec;  /* time of last access */
>         struct  timespec st_mtimespec;  /* time of last data modification */
>         struct  timespec st_ctimespec;  /* time of last file status change */
> 	...
[etc.]

I ran into this OpenBSD problem last week. I made a fix for it, and
even checked it into CVS in the "flaky1" branch. It's a slightly
unsatisfactory fix, since I left FILE-LENGTH stubbed out for now, but
all the other stat stuff, including all the stat stuff that SBCL
itself needs, still works. Unfortunately I had some GC problems too,
and in trying to fix them seem to have screwed everything up, not only
for OpenBSD but for Linux too. Even more unfortunately, in trying to
fix those problems I've been bewildered for days. So the "flaky1"
changes haven't been merged into the main branch, because then no one,
Linux or *BSD, would be able to compile from CVS.:-(

Unscrewing this at least for Linux is currently my first SBCL
development priority. (Unscrewing it for OpenBSD would be ordinarily
be just as high a priority, since I want to develop on my OpenBSD
laptop, except that some of the confusion over the last week has been
caused by OpenBSD 2.8 kernel crashes, while Linux has remained
reliable. At this point I certainly don't need any more confusion, so
I'm focusing on Linux.)

After that, OpenBSD remains a reasonably high priority. Unfortunately,
the problems begun last week have been a rather humbling experience --
it's remarkable how confused I've gotten.. -- and I don't know whether
I'll get tripped up by more OpenBSD kernel bugs, so I don't have much
of a guess whether the OpenBSD fixes will be done today or this
weekend or what.

-- 
William Harold Newman <william.newman@...>
"Tweak alpha so it sends SIGBUS for unaligned access, and does NOT
do a fixup. This encourages people to fix their code." -- a commit
note from <http://www.OpenBSD.org/plus29.html>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

On Thu, May 17, 2001 at 07:57:50AM -0500, William Harold Newman wrote:
> On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote:
> > Yes, but as "compensation" it seems that it doesn't work on BSD,
> > especially OpenBSD, anymore.
[..]
> After that, OpenBSD remains a reasonably high priority. Unfortunately,
> the problems begun last week have been a rather humbling experience --
> it's remarkable how confused I've gotten.. -- and I don't know whether
> I'll get tripped up by more OpenBSD kernel bugs, so I don't have much
> of a guess whether the OpenBSD fixes will be done today or this
> weekend or what.

I spent some time looking at this yesterday and the day before. I
rather expected that I'd be able to see the problem in the diffs
between the current version and the last working version if I just
looked carefully enough, but no luck.

I also panicked OpenBSD again, and this time I got a trace and 
sent in a bug report.

I'll probably continue investigating the problem by trying to learn
why the garbage collector is complaining after warm init saves
sbcl.core. With luck, I can localize that problem in a manageable
region by commenting out more and more of warm init until it goes
away, then poke around with gdb or assertions or something to see
what's going on. But I don't know how long that will take, or how many
hours per day I'll devote to it. OS panics are discouraging..

-- 
William Harold Newman <william.newman@...>
"As a simple example, a method named isValid(x) should as a
side effect convert x to binary and store the result in a
database." -- http://mindprod.com/unmain.html
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

(The original message I'm replying to was on sbcl-help, so I'm posting
this there. But I've also talked about this problem on sbcl-devel, so
I'm posting it there too.)

On Tue, May 22, 2001 at 11:34:16AM -0500, William Harold Newman wrote:
> On Thu, May 17, 2001 at 07:57:50AM -0500, William Harold Newman wrote:
> > On Wed, May 16, 2001 at 04:02:34PM +0200, Hannah Schroeter wrote:
> > > Yes, but as "compensation" it seems that it doesn't work on BSD,
> > > especially OpenBSD, anymore.
> [..]
> > After that, OpenBSD remains a reasonably high priority. Unfortunately,
> > the problems begun last week have been a rather humbling experience --
> > it's remarkable how confused I've gotten.. -- and I don't know whether
> > I'll get tripped up by more OpenBSD kernel bugs, so I don't have much
> > of a guess whether the OpenBSD fixes will be done today or this
> > weekend or what.
[..] 
> I'll probably continue investigating the problem by trying to learn
> why the garbage collector is complaining after warm init saves
> sbcl.core. With luck, I can localize that problem in a manageable
> region by commenting out more and more of warm init until it goes
> away, then poke around with gdb or assertions or something to see
> what's going on. But I don't know how long that will take, or how many
> hours per day I'll devote to it. OS panics are discouraging..

sbcl-0.6.12.17, now committed to CVS, works on OpenBSD again, for the
first time since the Alpha patches were committed.

The necessary fix was to change the memory map, moving the control
stack out of its previous address range.

The bug was in fact found as suggested above, by figuring out why the
GC was complaining after warm init saves sbcl.core. The process was
complicated by my attempts to use gdb to do so, which never worked.
Eventually I just found it by bisection, rebuilding smaller and
smaller subsets of the program in order to find what functionality was
required to cause the corruption to occur.

(Judging from the behavior of the new trymap utility, the same address
space conflict has existed at least since OpenBSD 2.7 (the oldest
version I can test conveniently). So it's unclear to me how the
pre-Alpha-patches versions of SBCL managed to work, since they all
used the same address space mapping.)

-- 
William Harold Newman <william.newman@...>
"The beatings will continue until morale improves." -- ??
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C