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 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.
I am using the build from master branch with the patch for #3145 and
cannot make it run under gdb:
$ gdb ../racket-lang/racket/racket/bin/racket
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../racket-lang/racket/racket/bin/racket...
(No debugging symbols found in ../racket-lang/racket/racket/bin/racket)
(gdb) run
Starting program:
/home/joe/Projects/Programming/racket-lang/racket/racket/bin/racket
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to Racket v7.7.0.4.
[New Thread 0x7ffff7fcb700 (LWP 6410)]
Thread 1 "racket" received signal SIGSEGV, Segmentation fault.
0x00005555555e14fe in scheme_gmp_tls_unload ()
(gdb)
The same happens for the binary with debug symbols:
gdb ../racket-lang/racket/racket/src/build/racket/racket3m
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
../racket-lang/racket/racket/src/build/racket/racket3m...
(gdb) run
Starting program:
/home/joe/Projects/Programming/racket-lang/racket/racket/src/build/racket/racket3m
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to Racket v7.7.0.4.
[New Thread 0x7ffff7fcb700 (LWP 6422)]
Thread 1 "racket3m" received signal SIGSEGV, Segmentation fault.
scheme_gmp_tls_unload (s=0x7ffff6114480, data=0x0) at
../../../racket/gc2/../src/gmp/gmp.c:5822
5822 s[0] = 0;
(gdb)
I am running Ubuntu 19.10's default gdb:
$ gdb --version
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
I assume gmp is used for bignum implementation (didn't check yet), so it
might be relevant as well:
ii libgmp-dev:amd64 2:6.1.2+dfsg-4
amd64 Multiprecision arithmetic library
developers tools
ii libgmp10:amd64 2:6.1.2+dfsg-4
amd64 Multiprecision arithmetic library
ii libgmp10:i386 2:6.1.2+dfsg-4
i386 Multiprecision arithmetic library
ii libgmpxx4ldbl:amd64 2:6.1.2+dfsg-4
amd64 Multiprecision arithmetic library (C++
bindings)
ii python-gmpy:amd64 1.17-4
amd64 interfaces GMP to Python for fast,
unbound-precision computations
I will pull latest master and re-try, but that is really just a blind guess.
Cheers,
Dominik
--
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/01505bda-23c8-c7b0-398a-ad55fe9d4c6c%40trustica.cz.
