Meaning of locked by a dead stack or unrecognized lock


Does anyone know what could cause an error like this:

  Trying to lock #<MP:LOCK "file-store-lock" Locked once by
  "hunchentoot-worker-149932" 4100018B0B> : Waiting for a lock that is
  locked by a dead stack or unrecognized lock 149914

What I'm doing is reading some data from the middle of a 19GB file.
Like this pseudo-code:

  (mp:with-lock (fs-lock)
    (with-timeout (*timeout*)
      (file-position fs-stream offset)
      (read-sequence buf fs-stream)))

This code is called from multiple threads on 64bit Linux LispWorks
5.1.  *timeout* is 10 and with-timeout is a macro that uses a timer to
call mp:process-interrupt after *timeout* seconds.

I would think that mp:with-lock would guarantee that the lock would be
cleared and I wouldn't see this error.

Cheers,
Chris Dean

Re: Meaning of locked by a dead stack or unrecognized lock

Unable to parse email body. Email id is 8096

Re: Meaning of locked by a dead stack or unrecognized lock

owner-lisp-hug@lispworks.com wrote on 05/02/2008 03:32:59 PM: > > Are you using with-timeout in any other way? It probably won't go wrong > inside mp:with-lock like that, but the implementation using > mp:process-interrupt to create an asynchronous throw is inherently dangerous > if it occurs in running code (rather than while sleeping) because it can > defeat some uses of unwind-protect. > > - > Martin Simmons > LispWorks Ltd > http://www.lispworks.com/ >
Is there a recommended way to establish a watchdog for a running process, then? We've been setting up a timer and killing a watched thread using an independent process, but it's still effectively interrupting the process and asking it to commit suicide to clean up any resources.

Re: Meaning of locked by a dead stack or unrecognized lock

Martin Simmons <martin@lispworks.com> writes:
>>>>>> On Thu, 01 May 2008 10:24:05 -0700, Chris Dean said:
>>   Trying to lock #<MP:LOCK "file-store-lock" Locked once by
>>   "hunchentoot-worker-149932" 4100018B0B> : Waiting for a lock that is
>>   locked by a dead stack or unrecognized lock 149914
>
> Is it a transient problem or is the lock still locked after you get into the
> debugger?  

When I see this error, the error is logged and the thread is deleted.
The thread holding the lock eventually lets go of the lock and work
continues.

> Does the process "hunchentoot-worker-149932" (or whatever printing
> the lock object show) still exist at that point?

Yes the 149932 thread still exists.  Most of the time, the app will
create another thread and try again -- that is usually successfull.

Sometimes (rarely), I never get out of this state and the app wedges.
When the app wedges, the thread that is holding the lock never exits
and I am unable to mp:process-kill it or attach to it in the debugger.

> Are you using with-timeout in any other way?  It probably won't go wrong
> inside mp:with-lock like that, but the implementation using
> mp:process-interrupt to create an asynchronous throw is inherently dangerous
> if it occurs in running code (rather than while sleeping) because it can
> defeat some uses of unwind-protect.

Good to know, thanks.  I'm using it one other place, but only after
that mp:with-lock returns (that is, in another function called later).

Cheers,
Chris Dean