Hi Andrew,
Andrew Gaylard writes:
> Inspection of the remqueue function shows
> that the logic is not correct when removing the last entry in the queue.
Indeed, thanks very much for debugging this!
I pushed a fix to stable-2.0.
> However it now hangs somewhere else (which may be an unrelated pr
On 04/29/13 12:10, Mark H Weaver wrote:
Hi Andrew,
On 28 April 2013 03:57, Andrew Gaylard 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
Hello,
On Mon, Apr 29, 2013 at 6:10 AM, Mark H Weaver wrote:
> Any ideas?
>
> Thanks,
>Mark
>
>
It should be possible to use a watchpoint in GDB to figure out what code is
corrupting that piece of memory. It probably won't tell us exactly what's
going on, but it would be interesting
Hi Andrew,
Andrew Gaylard writes:
> On 04/28/13 03:07, Daniel Hartwig wrote:
>> On 28 April 2013 03:57, Andrew Gaylard 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 fee
On 29 April 2013 14:56, Andrew Gaylard wrote:
> On 04/28/13 03:07, Daniel Hartwig wrote:
>>
>> On 28 April 2013 03:57, Andrew Gaylard 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,
>
>
On 04/28/13 03:07, Daniel Hartwig wrote:
On 28 April 2013 03:57, Andrew Gaylard 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, a
Hi,
Andrew Gaylard skribis:
> (gdb) bt
> #0 0x7e77b5f4 in enqueue (q=0x1010892c0, t=0x1018aac20) at
> threads.c:309
> #1 0x7e77bc20 in block_self (queue=0x1010892c0,
> sleep_object=0x1010892d0, mutex=0x1019eef00, waittime=0x0) at
> threads.c:452
> #2 0x7e77df50 in fat_
On 28 April 2013 03:57, Andrew Gaylard wrote:
> Those 0x304 values look dodgy to me, and explain why the
> SCM_SETCDR causes an invalid memory access.
>
0x304 is SCM_EOL.
>
> Is this even related to the use of queues,
Not (ice-9 q) or (container async-queue). The ‘enqueue’ procedure
here is in
Hi guile hackers,
I'm experiencing the VM coring in a repeatable manner.
My application launches a number of threads, which pass objects
from one thread to another via queues (ice-9 q). To ensure thread-
safety, the queues are actually accessed via (container async-queue)
from guile-lib-0.2.2;
