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 so far? My thought go along the lines:
> * flonums are boxed - but for some operations they may be immediate
> * apparently it is a busy-wait loop in RTT, otherwise 100% CPU usage is 
> impossible with this workload
> * unsafe ops are always suspicious, but again, the problem shows up even 
> when I switch to the safe versions - it just takes longer time
> * which means, the most probable cause is a race condition

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.

That could potentially tell us, for example, that it's a problem with
synchronization for a GC (where one of the OS threads that run futures
doesn't cooperate for some reason) or a problem with a the main thread
performing some specific work on a future thread's behalf.

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to