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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5eb5503d.1c69fb81.ae391.7291SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
