[Openmcl-devel] bogus objects

[Gary Byers]

On Fri, 12 Nov 2004, Cyrus Harmon wrote:

>
> I thought I could reproduce this easily, but upon further exercising of
> the code, it is proving difficult. I did manage to trigger another
> error with a bogus object, but this didn't drop me in to the debugger.
>
> Caught error: No applicable method for args:
>   (#<BOGUS object @ #x67DC506>)
>   to #<STANDARD-GENERIC-FUNCTION CLOSE #x60C0C36>

[...]

>
> Sounds like araneida is doing something funky somewhere along the line
> in dealing with threaded requests. I'll keep digging. Meanwhile,
> araneida traps these errors and reports them via
>
>       (ccl:print-call-history :detailed-p nil)
>
> in a debugger hook function, after having Is there a better way to find
> out where exactly the error occurred, not just where we ended up?

Not really.  You can make the GC run pretty rigorous (and slow) consistency
checks before and after it runs; if it finds something bad, it'll drop
into the kernel debugger with a cryptic message.  If it's a reproducible
case, it's sometimes possible to work back from there to see how the
bad thing got to be bad, but that's difficult.

Both of the backtraces seem to indicate that something that should have
been a stream wasn't a stream (or anything else ...) anymore.

Aside from an outright GC bug (or dangling references to stack-allocated
objects), the other way of getting "bogus objects" is to just step on
memory.  If a little slice of memory looks like:

|header for |                |header for|             |
|4 char     |  A | B | C | D |STREAM    | <clos stuff>|
| string    |                | instance |             |


and something like:

(defun set-schar-or-clobber-memory (s i c)
  (declare (optimize (speed 3) (safety 0)))
  (setf (schar s i c)))

is called to store an #\E beyond the end of that string, the #\E might
be stored in the middle of the header that describes the stream instance
(or, depending on the value of I, perhaps in the middle of some other
object several megabytes away