Re: The 2.0.9 VM cores in enqueue (threads.c:309)

[Mark H Weaver <mhw@netris.org>]

Hi Andrew,

Andrew Gaylard <ag@computer.org> writes:

> On 04/28/13 03:07, Daniel Hartwig wrote:
>> On 28 April 2013 03:57, Andrew Gaylard <ag@computer.org> wrote:
>>> Those 0x304 values look dodgy to me, and explain why the
>>> SCM_SETCDR causes an invalid memory access.
>>>
>> 0x304 is SCM_EOL.
> Hi Daniel,
>
> Thanks for the feedback.
>
> Are you saying that the 0x304 values are fine, and the problem lies
> elsewhere?

As Daniel pointed out, 0x304 is SCM_EOL, i.e. the empty list '().

> #0 0xffffffff7e77b5f4 in enqueue (q=0x1010892c0, t=0x1018aac20) at
> threads.c:309
> #1 0xffffffff7e77bc20 in block_self (queue=0x1010892c0,
> sleep_object=0x1010892d0, mutex=0x1019eef00, waittime=0x0) at
> threads.c:452
> #2 0xffffffff7e77df50 in fat_mutex_lock (mutex=0x1010892d0,
> timeout=0x0, owner=0x904, ret=0xffffffff734f92ac) at threads.c:1473
[...]
> (gdb) list
> 304 SCM c = scm_cons (t, SCM_EOL);
> 305 SCM_CRITICAL_SECTION_START;
> 306 if (scm_is_null (SCM_CDR (q)))
> 307 SCM_SETCDR (q, c);
> 308 else
> 309 SCM_SETCDR (SCM_CAR (q), c);
> 310 SCM_SETCAR (q, c);
> 311 SCM_CRITICAL_SECTION_END;
> 312 return c;
> 313 }
[...]
> (gdb) p *SCM2PTR(q)
> $26 = {word_0 = 0x304, word_1 = 0x1039c4c20}

What's happening here is that the wait queue (m->waiting in fat_mutex)
is somehow getting corrupted.  The code above ('enqueue' in threads.c)
is trying to add a new element to the queue.  The queue is represented
as a pair whose CDR is the list of items in the queue, and whose CAR
points to the last pair of that list.  Somehow, the CAR is becoming null
even though the CDR is non-empty.  This should never happen.

I looked through the relevant code, and it's not obvious to me how this
could happen.  The only functions I see that manipulate this queue are
'enqueue', 'remqueue', and 'dequeue', all static functions in threads.c.
As far as I can see, these functions maintain the invariant that the CAR
is null if and only if the CDR is null.  All queue manipulation is done
between SCM_CRITICAL_SECTION_START and SCM_CRITICAL_SECTION_END (defined
in async.h) which lock a single global pthread mutex.

Any ideas?

     Thanks,
       Mark