[vmkit-commits] FatLock assertion failure?

[Nicolas Geoffray]

Thanks Will for debugging the problem! Indeed, I commented the releasing of
the fat lock and it worked without any crashes. That's great news because
it looks like we nailed it. The bad news though is that if we don't release
a fat lock, it will never be able to get used again. Even worst is if we
need to keep a pointer to the associated object. The lock will just keep
that object alive forever.

If it helps, I'm ok with submitting a change that basically comments out
the release of a FatLock. When I'll have time, I'll investigate more at
which point do we have a race.

Cheers,
Nicolas

On Thu, Dec 1, 2011 at 12:49 AM, Will Dietz <wdietz2 at illinois.edu> wrote:

> On Tue, Nov 29, 2011 at 10:01 AM, Nicolas Geoffray
> <nicolas.geoffray at gmail.com> wrote:
> > Hi Will,
> >
> > On Tue, Nov 29, 2011 at 3:59 PM, Will Dietz <wdietz2 at illinois.edu>
> wrote:
> >>
> >> Hi,
> >>
> >> On both runtimes, I'm seeing the following assertion occur
> >> periodically (unpredictably, same code sometimes tickles it other
> >> times not)
> >>
> >> j3: /home/will/vmkit-svn/lib/vmkit/CommonThread/ObjectLocks.cpp:305:
> >> bool vmkit::FatLock::acquire(gc *): Assertion `obj->header &
> >> ThinLock::FatMask' failed.
> >
> > That's because you have too many cores :).... That's a lame answer. The
> real
> > answer is that there is a bug somewhere in the locking implementation. I
> > also experience in on my desktop machine (8 cores), but never on my
> laptop
> > (2 cores).
> > Nicolas
> >
>
> Thanks!
>
> Inspired by your response, I looked into this a bit and seem to have a
> bit more on the issue:
>
> The problem occurs when we try to deflate a fat lock back to a thin
> lock--there's a race on the object headers that makes the guard (that
> wants to be "does anyone have a pointer to this lock anywhere") unsafe
> (ObjectLocks.cpp:278-279).  Indeed (from my limited understanding of
> the literature, gulp) this seems to be a tricky problem in general and
> not just a bug of this implementation.
>
> Given this, and that we probably want locks to work on SMP machines
> (well, I sure do! :D), it seems we have at least two solutions:
>
> * Implement a more complicated locking solution ("tasuki" locks?).
> * Disallow deflating of fat locks altogether.  I've done this locally
> to great success--a lot of mysterious crashes/assertion failures are
> now gone.  Downside is potential performance hit in terms of locking
> overhead and lock resource utilization.
>
> I'm inclined to suggest we just go with the latter, and put the former
> on the TODO list... but of course it's up to you, and I'm curious what
> your thoughts on all this are :).
>
> Thanks!
>
> ~Will
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/vmkit-commits/attachments/20111201/92e27ec8/attachment.html>