[Openmcl-devel] new 0.14 alpha binaries

[Gary Byers]

On Wed, 19 Mar 2003, Sven Van Caekenberghe wrote:

> On Tuesday, March 18, 2003, at 11:51 PM, Sven Van Caekenberghe wrote:
>
> > Tomorrow, I will test this combination with my web application.
>
> Apart from the success, I did encounter a strange bug while LSP are
> compiled at run time:
>
> ? (run :debug t)
> Starting Server on port 2001 in single thread DEBUG mode
> 127.0.0.1 - - [Wed, 19 Mar 2003 09:44:07 GMT] "GET /lcars/weblogout
> HTTP/1.1" 200 -1
> 127.0.0.1 - - [Wed, 19 Mar 2003 09:44:07 GMT] "GET /lcars/lcars.css
> HTTP/1.1" 200 1804
> - - - [20030319T094412GMT] login #<SESSION 28H5J9KKONAC8 (3257055852)>
> #<WEB-USER sven (501)>
> 127.0.0.1 - - [Wed, 19 Mar 2003 09:44:12 GMT] "POST /lcars/weblogin
> HTTP/1.1" 200 -1
> 127.0.0.1 - - [Wed, 19 Mar 2003 09:44:13 GMT] "GET /lcars/lcars.css
> HTTP/1.1" 200 1804
> 127.0.0.1 - - [Wed, 19 Mar 2003 09:44:25 GMT] "GET /lcars/pi.lsp
> HTTP/1.1" 200 -1
>  > Error in process listener(2): value #<LREG 66 GPR [22]> is not of the
> expected type SIMPLE-VECTOR.
>  > While executing: CCL::ALLOC-VARPARTS-VECTOR
>  > Type :POP to abort.
> Type :? for other options.
> 1 > :b
>

At first glance, this looks like a GC bug (or at least the symptoms look
similar to a GC bug I was experiencing a few months ago.)  If so, I
may be able to find it just by compiling while the paserve demo is
running.

One thing that helps a little while testing (it's certainly not suitable
for production use) is to enable some extra integrity checking in the
GC; this can be done by setting a bit in a fixnum-valued variable that's
used to communicate between lisp code and the GC:

? (setq ccl::*gc-event-status-bits*
        (logior ccl::*gc-event-status-bits*
                (ash 1 ccl::$gc-integrity-check-bit)))

When a GC happens with that bit set, it'll run some fairly rigorous
consistency checks before and after each GC (the consistency checks
typically take several times longer than the GC does.)  If those
checks find inconsistencies (pointers not pointing to the right
places, missing or invalid headers, headers where there shouldn't
be headers) they'll be cryptically reported in the low-level debugger.

The inconsistencies that might be reported in cases like this
(probably) aren't interesting in and of themselves; there shouldn't
ever be any inconsistencies, so the interesting question is whether
or not any were reported.

The compiler allocates lots of internal data structures (at some
point, there's a structure object for every machine instruction
being assembled) that become garbage as soon as it's done with
them.  It might be interesting to see how well the GC could keep
up with that, but the complier maintains a half-dozen or so
freelists and manages the objects itself.  (Empty freelists
are ordinarily allocated for each lisp thread: another way to
deal with potential resource-contention problems is to avoid
them completely.)

The error message above indicates that a freelist contained the
wrong type of object.  That "can't happen" under ordinary
circumstances, but may be a symptom of a thread being confused
about where free memory is and isn't (e.g., if that thread's
notions about that weren't updated properly when another thread
GCed.)

I just looked at how the GC handles suspect cases and the code
looks right to me; it looked right before I eventually found
the last similar-looking bug, so that isn't always conclusive.

> Gary, I'll send you a (:b t) directly.

Thanks.  In this particular case it didn't seem to reveal anything,
but backtrace information is often helpful.

>
> --
> Sven Van Caekenberghe - mailto:sven at beta9.be
> Beta Nine - software engineering - http://www.beta9.be
> .Mac - svc at mac.com - http://homepage.mac.com/svc
>
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel