On 29 April 2013 14:56, Andrew Gaylard <a...@computer.org> wrote:
> On 04/28/13 03:07, Daniel Hartwig wrote:
>>
>> On 28 April 2013 03:57, Andrew Gaylard <a...@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?
> (e.g. heap corruption, ...)
Yes and no. They are fine in the sense that it is a valid SCM value,
and expected in some situations. I wanted to investigate the specific
code before commenting further. Certainly it should never be the
subject of ‘SCM_SETCDR’.
The value of C at that point:
> (gdb) p *SCM2PTR(c)
> $28 = {word_0 = 0x1018aac20, word_1 = 0x304}
is as expected, a one-element list. Q however:
> (gdb) p *SCM2PTR(q)
> $26 = {word_0 = 0x304, word_1 = 0x1039c4c20}
should not occur according to my reading of the three queue procedures
in threads.c. The car (word_0) is the final pair in the queue and
should only be ‘()’ (or 0x304) when the cdr is also. Only two lines
that could assign this value, and both appear fine unless one of the
conditions is failing somehow.
For the moment I have no more idea. I briefly suspected the
initialization of ‘prev = q’ in ‘remqueue’ being outside the critical
section, but as Q itself never changes that can be dismissed.
So needs more looking at, maybe there is some other code that modifies
these queues.
Regards
