[Openmcl-devel] bogus objects

[Cyrus Harmon]

On Nov 12, 2004, at 10:18 AM, Gary Byers wrote:

> The other way in which invalid/bogus objects can be created is as a
> result of a GC bug: if the GC moves something but doesn't correctly
> update all references to that thing, the old pointer isn't necessarily
> pointing at anything.
>
> The printer can -sometimes- catch this sort of thing; it'll 
> occasionally
> yield false positives (it's very hard in general to tell if something's
> legitimately stack-allocated in a stack belonging to another thread),
> and it can be fooled by other cases.
>
> A couple of months ago, I made a change in the bleeding-edge kernel
> that affected how the GC suspended and resumed threads on Darwin. I
> wonder if I got something wrong in there somewhere (and threads either
> aren't getting suspended or the GC's notion of register values is
> incorrect.)  The fact that backtrace choked trying to print a function
> near the bottom of the stack makes me suspicious of that.
>
> Are you running the kernel from the bleeding-edge CVS tree ?

No, this is the 0.14-cvs tree, not the dev tree.

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>
(F0268B80) : 0 "ARANEIDA::HANDLER-DEBUGGER-HOOK" 192
(F0268B90) : 1 "CCL::BREAK-LOOP-HANDLE-ERROR" 256
(F0268BA0) : 2 NIL NIL
(F0268BB0) : 3 "CCL::%%STANDARD-COMBINED-METHOD-DCODE" 148
(F0268BC0) : 4 NIL NIL
(F0268BD0) : 5 "CCL::%ERROR" 104
(F0268BE0) : 6 "#<CCL::STANDARD-KERNEL-METHOD NO-APPLICABLE-METHOD 
(T)>" 48
(F0268BF0) : 7 NIL NIL
(F0268C00) : 8 "FORMAT" 124
(F0268C10) : 9 NIL NIL
(F0268C20) : 10 NIL NIL
(F0268C30) : 11 "#<STANDARD-METHOD ARANEIDA:REQUEST-SEND-HEADERS 
(ARANEIDA:REQUEST)>" 516
(F0268C40) : 12 NIL NIL
(F0268C50) : 13 "CCL::%%CHECK-KEYWORDS" 172
(F0268C60) : 14 NIL NIL
(F0268C70) : 15 "#<STANDARD-METHOD ARANEIDA:REQUEST-SEND-ERROR 
(ARANEIDA:REQUEST T)>" 368
(F0268C80) : 16 NIL NIL
(F0268C90) : 17 "ARANEIDA::DO-IT" 452
(F0268CA0) : 18 NIL NIL
(F0268CB0) : 19 "ARANEIDA::THREADED-HTTP-LISTENER-ACCEPT-ONE-REQUEST" 
696
(F0268CF0) : 20 "Anonymous Function #x648C0BE" 76
(F0268D00) : 21 "CCL::RUN-PROCESS-INITIAL-FORM" 400
(F0268D30) : 22 NIL NIL
(F0268D40) : 23 "Anonymous Function #x6101D3E" 152
(F0268D60) : 24 "Anonymous Function #x60F491E" 172;; 4 spare threads < 
5, adding another


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?

Thanks again,

Cyrus