Hello,
I'll add a lock at lines 1092-1096 of "newgc.c", and we'll see if that
helps.
should I open the issue or will you do it? (Speaking of race conditions...).
I'll re-run the tests with the lock once it is in the repo - sometimes
it takes hours for this bug to exhibit and with 8 HTs the
At Sat, 9 May 2020 07:18:01 +0200, Dominik Pantůček wrote:
> would this be enough to open an issue for that?
>
> (gdb) info threads
>Id Target IdFrame
> * 1Thread 0x77c1b300 (LWP 19075) "tut22.rkt"
> mark_backpointers
Hello,
The most useful information here is likely to be a stack trace from
each OS-level thread at the point where the application is stuck.
would this be enough to open an issue for that?
(gdb) info threads
Id Target IdFrame
* 1Thread
You will want to do `handle SIGSEGV nostop noprint` when you start
gdb. Racket BC uses the SEGV handler to implement the GC write
barrier, so you'll want to skip those.
Sam
On Fri, May 8, 2020 at 9:36 AM Dominik Pantůček
wrote:
>
> Hello,
>
> On 08. 05. 20 14:27, Matthew Flatt wrote:
> > At
Hello,
On 08. 05. 20 14:27, Matthew Flatt wrote:
At Fri, 8 May 2020 09:34:32 +0200, Dominik Pantůček wrote:
Apart from obvious strace (after freeze) and gdb (before/after freeze)
debugging to find possible sources of this bug, is there even a remote
possibility of getting any clue how can this
At Fri, 8 May 2020 09:34:32 +0200, Dominik Pantůček wrote:
> Apart from obvious strace (after freeze) and gdb (before/after freeze)
> debugging to find possible sources of this bug, is there even a remote
> possibility of getting any clue how can this happen based on the
> information gathered
Hello fellow Racketeers,
my spare-time out-of-curiosity venture into using HPR (High-Performance
Racket) for creating a software 3D rendering pipeline seems to be
pushing the futures into rough edges.
The scenario is sort of "usual":
* 7 futures + 1 in RTT that form a binary tree
* GUI
7 matches
Mail list logo
