Hi Andrew,
On 28 April 2013 03:57, Andrew Gaylard <address@hidden> wrote:
Those 0x304 values look dodgy to me, and explain why the
SCM_SETCDR causes an invalid memory access.
(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