* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
@ 2017-08-23 22:20 Ludovic Courtès
2017-08-23 22:48 ` Ludovic Courtès
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-08-23 22:20 UTC (permalink / raw)
To: 28211
On current ‘core-updates’, the code in (guix build graft) triggers
random Guile crashes (GC issue? thread-safety issue?) when running on
Guile 2.2.2, as initially reported by Marius at
<https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00013.html>:
--8<---------------cut here---------------start------------->8---
grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
ERROR: In procedure put-bytevector: Wrong type argument in position 1 (expecting open output port): #<closed: file 8f1930>
builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
[...]
ludo@ribbon ~/src/guix/+core-updates$ guix gc --clear-failures $(guix gc --list-failures)
ludo@ribbon ~/src/guix/+core-updates$ guix build /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
La jena derivo estos konstruata:
/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
@ build-started /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - x86_64-linux /var/log/guix/drvs/3c//rrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv.bz2
grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
ERROR: In procedure put-bytevector: Wrong type argument in position 1 (expecting open output port): #<closed: file 7517e0>
builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
@ build-failed /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - 1 builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
guix build: error: build failed: build of `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed
ludo@ribbon ~/src/guix/+core-updates$ guix gc --clear-failures $(guix gc --list-failures)
ludo@ribbon ~/src/guix/+core-updates$ guix build /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
La jena derivo estos konstruata:
/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
@ build-started /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - x86_64-linux /var/log/guix/drvs/3c//rrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv.bz2
grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
ERROR: In procedure variable-ref: Not a variable: (194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255)
builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
@ build-failed /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - 1 builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---
The problem does not show up when running on a single thread:
--8<---------------cut here---------------start------------->8---
guix build: error: build failed: build of `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed
ludo@ribbon ~/src/guix/+core-updates$ guix gc --clear-failures $(guix gc --list-failures)
ludo@ribbon ~/src/guix/+core-updates$ guix build /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv --cores=1
La jena derivo estos konstruata:
/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
@ build-started /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - x86_64-linux /var/log/guix/drvs/3c//rrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv.bz2
grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
@ build-succeeded /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv -
/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1
--8<---------------cut here---------------end--------------->8---
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2017-08-23 22:20 bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Ludovic Courtès
@ 2017-08-23 22:48 ` Ludovic Courtès
2018-04-24 16:03 ` Ludovic Courtès
2018-07-02 10:28 ` Ludovic Courtès
2 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-08-23 22:48 UTC (permalink / raw)
To: 28211
ludo@gnu.org (Ludovic Courtès) skribis:
> On current ‘core-updates’, the code in (guix build graft) triggers
> random Guile crashes (GC issue? thread-safety issue?) when running on
> Guile 2.2.2, as initially reported by Marius at
> <https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00013.html>:
Commit e4925e00ca420737556e2039b4fa1c40121ee567 works around it by using
Guile 2.0 for these derivations.
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2017-08-23 22:20 bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Ludovic Courtès
2017-08-23 22:48 ` Ludovic Courtès
@ 2018-04-24 16:03 ` Ludovic Courtès
2018-05-08 21:55 ` Ludovic Courtès
2018-07-02 10:28 ` Ludovic Courtès
2 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2018-04-24 16:03 UTC (permalink / raw)
To: 28211
ludo@gnu.org (Ludovic Courtès) skribis:
> On current ‘core-updates’, the code in (guix build graft) triggers
> random Guile crashes (GC issue? thread-safety issue?) when running on
> Guile 2.2.2, as initially reported by Marius at
> <https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00013.html>:
The problem still shows up with Guile 2.2.3+. Some raw notes on clues I
have so far.
When running the grafting code under Helgrind, we get things like this:
--8<---------------cut here---------------start------------->8---
==30263== ----------------------------------------------------------------
==30263==
==30263== Lock at 0x5168F60 was first observed
==30263== at 0x4C34943: pthread_mutex_init (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x4EF36C3: scm_threads_prehistory (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F64D: scm_i_init_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2557: scm_i_init_thread_for_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2588: with_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x5185757: GC_call_with_stack_base (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x4EF2957: scm_with_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F5F1: scm_boot_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x400B5F: main (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/bin/guile)
==30263== Address 0x5168f60 is 0 bytes inside data symbol "scm_i_misc_mutex"
==30263==
==30263== Lock at 0x53AA240 was first observed
==30263== at 0x4C30D6D: mutex_trylock_WRK (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x4C349E6: pthread_mutex_trylock (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x517C9C3: GC_register_disappearing_link_inner (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x4F0585D: weak_set_add_x (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F05E1F: scm_c_weak_set_add_x (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF0964: scm_i_str2symbol (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF1162: scm_from_utf8_symboln (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EAA950: scm_c_public_ref (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4ED39BF: scm_compile_shell_switches (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4ED3A24: scm_shell (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F45C: invoke_main_func (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E81C59: c_body (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== Address 0x53aa240 is 0 bytes inside data symbol "GC_allocate_ml"
==30263==
==30263== Possible data race during write of size 8 at 0xB349528 by thread #8
==30263== Locks held: 1, at address 0x5168F60
==30263== at 0x4E85E65: scm_strerror (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4573E4F: ???
==30263== by 0x4E85F12: scm_syserror (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E8F228: scm_mkdir (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F0117C: vm_regular_engine (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F047D9: scm_call_n (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E78EB7: scm_call_with_unblocked_asyncs (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F0117C: vm_regular_engine (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F047D9: scm_call_n (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2495: really_launch (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E81C59: c_body (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F0117C: vm_regular_engine (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263==
==30263== This conflicts with a previous read of size 8 by thread #9
==30263== Locks held: 1, at address 0x53AA240
==30263== at 0x5182F70: GC_push_all_eager (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x518CA2C: GC_push_all_stacks (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x51834AC: GC_mark_some (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5178F7C: GC_stopped_mark (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5179A68: GC_try_to_collect_inner (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x517A43B: GC_collect_or_expand (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x517FD6A: GC_alloc_large (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5180182: GC_generic_malloc (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== Address 0xb349528 is on thread #8's stack
==30263== in frame #0, created by scm_strerror (???:)
==30263==
==30263== ----------------------------------------------------------------
==30263==
==30263== Lock at 0x5168F60 was first observed
==30263== at 0x4C34943: pthread_mutex_init (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x4EF36C3: scm_threads_prehistory (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F64D: scm_i_init_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2557: scm_i_init_thread_for_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2588: with_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x5185757: GC_call_with_stack_base (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x4EF2957: scm_with_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F5F1: scm_boot_guile (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x400B5F: main (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/bin/guile)
==30263== Address 0x5168f60 is 0 bytes inside data symbol "scm_i_misc_mutex"
==30263==
==30263== Lock at 0x53AA240 was first observed
==30263== at 0x4C30D6D: mutex_trylock_WRK (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x4C349E6: pthread_mutex_trylock (in /gnu/store/yiiz2cdfsx6rqvp1gvlz34pvrl0cjf5c-valgrind-3.13.0/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==30263== by 0x517C9C3: GC_register_disappearing_link_inner (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x4F0585D: weak_set_add_x (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F05E1F: scm_c_weak_set_add_x (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF0964: scm_i_str2symbol (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF1162: scm_from_utf8_symboln (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EAA950: scm_c_public_ref (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4ED39BF: scm_compile_shell_switches (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4ED3A24: scm_shell (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E9F45C: invoke_main_func (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E81C59: c_body (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== Address 0x53aa240 is 0 bytes inside data symbol "GC_allocate_ml"
==30263==
==30263== Possible data race during write of size 8 at 0xB3494F8 by thread #8
==30263== Locks held: 1, at address 0x5168F60
==30263== at 0x4EC2C2F: scm_i_default_port_conversion_strategy (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0xC3F0D9F: ???
==30263== by 0x4EEC5DE: scm_from_locale_stringn (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E85E69: scm_strerror (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E85F12: scm_syserror (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E8F228: scm_mkdir (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F0117C: vm_regular_engine (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F047D9: scm_call_n (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4E78EB7: scm_call_with_unblocked_asyncs (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F0117C: vm_regular_engine (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4F047D9: scm_call_n (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263== by 0x4EF2495: really_launch (in /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3/lib/libguile-2.2.so.1.3.0)
==30263==
==30263== This conflicts with a previous read of size 8 by thread #9
==30263== Locks held: 1, at address 0x53AA240
==30263== at 0x5182F70: GC_push_all_eager (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x518CA2C: GC_push_all_stacks (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x51834AC: GC_mark_some (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5178F7C: GC_stopped_mark (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5179A68: GC_try_to_collect_inner (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x517A43B: GC_collect_or_expand (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x517FD6A: GC_alloc_large (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== by 0x5180182: GC_generic_malloc (in /gnu/store/c4jrwbv7qckvnqa7f3h7bd1hh8rbg72y-libgc-7.6.0/lib/libgc.so.1.0.3)
==30263== Address 0xb3494f8 is on thread #8's stack
==30263== in frame #0, created by scm_i_default_port_conversion_strategy (???:)
--8<---------------cut here---------------end--------------->8---
I find it hard to draw any conclusions from this, though.
I was also able to gather backtraces at the time of one of these crashes
(here it’s “Wrong type to apply”) with GDB:
--8<---------------cut here---------------start------------->8---
(gdb) catch syscall exit_group
Catchpoint 1 (syscall 'exit_group' [231])
(gdb) condition 1 ($rdi != 0)
(gdb) r
Starting program: /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/bin/guile t.scm
ERROR: In procedure type-pointer:
ERROR: In procedure gdbscm_type_pointer: Wrong type argument in position 1 (expecting gdb:type): #f
Error while executing Scheme code.[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libthread_db.so.1".
[New Thread 0x7ffff5ea5700 (LWP 8359)]
[New Thread 0x7ffff5654700 (LWP 8360)]
[New Thread 0x7ffff4e03700 (LWP 8361)]
[New Thread 0x7ffff3ecd700 (LWP 8362)]
grafting '/gnu/store/w3hxb7hrafkhxplcf5qzvsc0fbipqb3i-perl-5.26.1' -> '/gnu/store/w3hxb7hrafkhxplcf5qzvsc0fbipqb3i-perl-5.XX.X'...
;;; (jobs 8)
[New Thread 0x7ffff35ac700 (LWP 8363)]
[New Thread 0x7fffead5b700 (LWP 8364)]
[New Thread 0x7ffff2d5b700 (LWP 8365)]
[New Thread 0x7ffff24f8700 (LWP 8366)]
[New Thread 0x7ffff1ca7700 (LWP 8367)]
[New Thread 0x7ffff1456700 (LWP 8368)]
[New Thread 0x7ffff0c05700 (LWP 8369)]
[New Thread 0x7fffebfff700 (LWP 8370)]
Wrong type to apply: "lib"
[Switching to Thread 0x7ffff2d5b700 (LWP 8365)]
Thread 8 "guile" hit Catchpoint 1 (call to syscall exit_group), 0x00007ffff5f65a88 in _exit ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
(gdb) thread apply all bt
Thread 13 (Thread 0x7fffebfff700 (LWP 8370)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff762caea in __lll_lock_wait ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff7625c65 in pthread_mutex_lock ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#6 0x00007ffff784f9ed in GC_notify_or_invoke_finalizers ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#7 0x00007ffff7851dcd in GC_generic_malloc_many ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#8 0x00007ffff785a2ce in GC_malloc_kind ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#9 0x00007ffff7b591c6 in scm_i_make_string ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b5b4d6 in scm_from_stringn ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b5b76e in scm_take_locale_stringn ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7aff4b3 in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#25 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#26 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#27 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#28 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#29 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#30 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#31 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 12 (Thread 0x7ffff0c05700 (LWP 8369)):
#0 0x00007ffff762c0b7 in do_futex_wait.constprop ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#1 0x00007ffff762c164 in __new_sem_wait_slow.constprop.0 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#2 0x00007ffff785dd62 in GC_stop_world ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 0x00007ffff7849f0e in GC_stopped_mark ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#4 0x00007ffff784aa69 in GC_try_to_collect_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#5 0x00007ffff784b43c in GC_collect_or_expand ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#6 0x00007ffff7850d6b in GC_alloc_large ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#7 0x00007ffff7851183 in GC_generic_malloc ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#8 0x00007ffff7851398 in GC_malloc_kind_global ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#9 0x00007ffff7aedabf in scm_make_bytevector ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#24 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#25 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#26 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 11 (Thread 0x7ffff1456700 (LWP 8368)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff5ecbc3e in __gconv_transform_internal_utf8 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#5 0x00007ffff43b09b0 in gconv ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/gconv/ISO8859-1.so
#6 0x00007ffff5ec7da7 in __gconv ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#7 0x00007ffff5ec7677 in iconv ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#8 0x00007ffff7b8155e in mem_cd_iconveh_internal ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7b8238c in mem_iconveh ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b5bd14 in scm_to_stringn ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7aff4e8 in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#25 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#26 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#27 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#28 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#29 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#30 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 10 (Thread 0x7ffff1ca7700 (LWP 8367)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff5f87ed5 in _lxstat ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#5 0x00007ffff5ee70bb in realpath@@GLIBC_2.3 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#6 0x00007ffff7aff4f3 in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#7 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#23 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#25 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 9 (Thread 0x7ffff24f8700 (LWP 8366)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff5f87ed5 in _lxstat ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#5 0x00007ffff5ee70bb in realpath@@GLIBC_2.3 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#6 0x00007ffff7aff4f3 in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#7 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#23 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#25 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 8 (Thread 0x7ffff2d5b700 (LWP 8365)):
#0 0x00007ffff5f65a88 in _exit ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff5edcab3 in __run_exit_handlers ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#2 0x00007ffff5edcb5a in exit ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#3 0x00007ffff7b42b9b in scm_primitive_exit ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#4 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#5 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#6 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#7 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#18 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#20 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 7 (Thread 0x7fffead5b700 (LWP 8364)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff762caea in __lll_lock_wait ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff7625c65 in pthread_mutex_lock ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#6 0x00007ffff78513b5 in GC_malloc_kind_global ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#7 0x00007ffff7b591c6 in scm_i_make_string ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b5b4d6 in scm_from_stringn ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7aff50b in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#25 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#26 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#27 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#28 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 6 (Thread 0x7ffff35ac700 (LWP 8363)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff762caec in __lll_lock_wait ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff7625c65 in pthread_mutex_lock ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#6 0x00007ffff78513b5 in GC_malloc_kind_global ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#7 0x00007ffff7b591c6 in scm_i_make_string ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b5b4d6 in scm_from_stringn ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7aff50b in scm_i_relativize_path ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b041f7 in scm_open_file_with_encoding ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b04333 in scm_i_open_file ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7ae7eb8 in scm_call_with_unblocked_asyncs ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7b61496 in really_launch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#21 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#24 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#25 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#26 0x00007ffff7b60c8d in launch_thread ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#27 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#28 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 5 (Thread 0x7ffff3ecd700 (LWP 8362)):
#0 0x00007ffff762c48c in sem_post@@GLIBC_2.2.5 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#1 0x00007ffff785d638 in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff762caea in __lll_lock_wait ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff7625c65 in pthread_mutex_lock ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#6 0x00007ffff784f7bd in GC_invoke_finalizers ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#7 0x00007ffff7b001d9 in scm_run_finalizers ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b00235 in finalization_thread_proc ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#17 0x00007ffff7b61958 in scm_with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#19 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 4 (Thread 0x7ffff4e03700 (LWP 8361)):
#0 0x00007ffff76297af in pthread_cond_wait@@GLIBC_2.3.2 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#1 0x00007ffff785d3f7 in GC_wait_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff78538fa in GC_help_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 0x00007ffff785d3cc in GC_mark_thread ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#4 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 3 (Thread 0x7ffff5654700 (LWP 8360)):
#0 0x00007ffff76297af in pthread_cond_wait@@GLIBC_2.3.2 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#1 0x00007ffff785d3f7 in GC_wait_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff78538fa in GC_help_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 0x00007ffff785d3cc in GC_mark_thread ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#4 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 2 (Thread 0x7ffff5ea5700 (LWP 8359)):
#0 0x00007ffff76297af in pthread_cond_wait@@GLIBC_2.3.2 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#1 0x00007ffff785d3f7 in GC_wait_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff78538fa in GC_help_marker ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 0x00007ffff785d3cc in GC_mark_thread ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#4 0x00007ffff76234d5 in start_thread ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff5f962cf in clone ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
Thread 1 (Thread 0x7ffff7fef480 (LWP 8355)):
#0 0x00007ffff5eda5c6 in sigsuspend ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libc.so.6
#1 0x00007ffff785d65a in GC_suspend_handler_inner ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#2 0x00007ffff785d70f in GC_suspend_handler ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#3 <signal handler called>
#4 0x00007ffff76297ad in pthread_cond_wait@@GLIBC_2.3.2 ()
from /gnu/store/n6acaivs0jwiwpidjr551dhdni5kgpcr-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
#5 0x00007ffff7b6200b in block_self ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#6 0x00007ffff7b624f0 in scm_timed_wait_condition_variable ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#7 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#8 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#9 0x00007ffff7af7977 in scm_primitive_eval ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#10 0x00007ffff7af79d3 in scm_eval ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#11 0x00007ffff7b42a30 in scm_shell ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#12 0x00007ffff7b0e45d in invoke_main_func ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#13 0x00007ffff7af0c5a in c_body ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#14 0x00007ffff7b7017d in vm_regular_engine ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#15 0x00007ffff7b737da in scm_call_n ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#16 0x00007ffff7b629a6 in catch ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#17 0x00007ffff7af1240 in scm_i_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#18 0x00007ffff7af12d5 in scm_c_with_continuation_barrier ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#19 0x00007ffff7b615bc in with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#20 0x00007ffff7856758 in GC_call_with_stack_base ()
from /gnu/store/7ivzka4by2casz1p65l8pm9vjnis0zjw-libgc-7.6.0/lib/libgc.so.1
#21 0x00007ffff7b61958 in scm_with_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#22 0x00007ffff7b0e5f2 in scm_boot_guile ()
from /gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/lib/libguile-2.2.so.1
#23 0x0000000000400b60 in main ()
--8<---------------cut here---------------end--------------->8---
To be continued…
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-04-24 16:03 ` Ludovic Courtès
@ 2018-05-08 21:55 ` Ludovic Courtès
2018-05-09 0:32 ` Mark H Weaver
2018-05-10 15:48 ` bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Mark H Weaver
0 siblings, 2 replies; 23+ messages in thread
From: Ludovic Courtès @ 2018-05-08 21:55 UTC (permalink / raw)
To: 28211; +Cc: Andy Wingo
[-- Attachment #1: Type: text/plain, Size: 80346 bytes --]
Hello Andy & Mark,
ludo@gnu.org (Ludovic Courtès) skribis:
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> On current ‘core-updates’, the code in (guix build graft) triggers
>> random Guile crashes (GC issue? thread-safety issue?) when running on
>> Guile 2.2.2, as initially reported by Marius at
>> <https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00013.html>:
>
> The problem still shows up with Guile 2.2.3+.
Here’s a clearer backtrace:
--8<---------------cut here---------------start------------->8---
Core was generated by `/gnu/store/38553wfz0jwlgbw13pk99xl79pbfx58d-guile-2.2.3/bin/guile t.scm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f7019db0d79 in scm_is_pair (x=0x0) at ../libguile/pairs.h:159
159 ../libguile/pairs.h: Dosiero aŭ dosierujo ne ekzistas.
[Current thread is 1 (Thread 0x7f6fe6f5d700 (LWP 2856))]
(gdb) thread apply all bt
Thread 18 (Thread 0x7f7015859700 (LWP 2845)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x12715a0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x1271578) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x1271578, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x1271578, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x1271540, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x12715a0, vp=0x144ecf0, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1423960>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1423960>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1423960>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x12715a0, vp=0x144ecf0, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371a80>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x1633240) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7015858e60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x12715a0, vp=0x144ecf0, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1423d60>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1423d60>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1423d60>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1423ce0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1423c60) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7015858e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7015858e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7015858e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7015858e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7015858ec8, data=data@entry=0x7f7015858ef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7015858ef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x1633240, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x1633240) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7015859700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 17 (Thread 0x7f701714f700 (LWP 2842)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1271ae0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x1271ab8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x1271ab8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x1271ab8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x1271a80, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271ae0, vp=0x144eea0, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 163cfc0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 163cfc0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 163cfc0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271ae0, vp=0x144eea0, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371b40>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x16333c0) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f701714ee60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271ae0, vp=0x144eea0, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 141e400>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 141e400>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 141e400>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x141e380,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x141e300) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f701714ee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f701714ee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f701714ee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f701714ee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f701714eec8, data=data@entry=0x7f701714eef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f701714eef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x16333c0, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x16333c0) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f701714f700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 16 (Thread 0x7f7006f5d700 (LWP 2849)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e4ca0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e4c78) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e4c78, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e4c78, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e4c40, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4ca0, vp=0x144eab0, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1513fe0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1513fe0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1513fe0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4ca0, vp=0x144eab0, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371980>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149ed00) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7006f5ce60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4ca0, vp=0x144eab0, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 141f440>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 141f440>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 141f440>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x141f400,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x141f380) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7006f5ce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7006f5ce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7006f5ce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7006f5ce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7006f5cec8, data=data@entry=0x7f7006f5cef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7006f5cef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149ed00, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149ed00) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7006f5d700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 15 (Thread 0x7f7007fff700 (LWP 2847)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1271220) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x12711f8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x12711f8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x12711f8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x12711c0, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271220, vp=0x144ebd0, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 146fe80>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 146fe80>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 146fe80>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271220, vp=0x144ebd0, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371a00>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x1633100) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7007ffee60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271220, vp=0x144ebd0, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 146fa00>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 146fa00>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 146fa00>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x146f8e0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x146f8a0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7007ffee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7007ffee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7007ffee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7007ffee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7007ffeec8, data=data@entry=0x7f7007ffeef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7007ffeef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x1633100, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x1633100) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7007fff700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 14 (Thread 0x7f70160ab700 (LWP 2844)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1271764) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x1271738) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x1271738, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x1271738, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x1271700, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271764, vp=0x144ed80, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 12b5be0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 12b5be0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 12b5be0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271764, vp=0x144ed80, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371ac0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x16332c0) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f70160aae60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271764, vp=0x144ed80, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1642e40>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1642e40>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1642e40>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1642e20,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1642e00) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70160aae60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70160aae60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70160aae60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70160aae60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f70160aaec8, data=data@entry=0x7f70160aaef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f70160aaef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x16332c0, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x16332c0) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f70160ab700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 13 (Thread 0x7f6fe77ae700 (LWP 2855)):
#0 vm_regular_engine (thread=0x2, vp=0x144e750, registers=0xa, resume=343596440) at vm-engine.c:1982
#1 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1428720>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#2 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1428720>) at eval.c:481
#3 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1428720>) at async.c:400
#4 0x00007f7019e0e17d in vm_regular_engine (thread=0x2, vp=0x144e750, registers=0xa, resume=343596440) at vm-engine.c:784
#5 0x00007f7019e117da in scm_call_n (proc=#<program 1371800>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#6 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#7 0x00007f7019dff496 in really_launch (d=0x149e620) at threads.c:794
#8 0x00007f7019d8ec5a in c_body (d=0x7f6fe77ade60) at continuations.c:422
#9 0x00007f7019e0e17d in vm_regular_engine (thread=0x2, vp=0x144e750, registers=0xa, resume=343596440) at vm-engine.c:784
#10 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 14289c0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#11 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 14289c0>) at eval.c:481
#12 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 14289c0>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1428860,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14287e0) at throw.c:137
#13 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#14 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe77ade60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe77ade60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#15 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe77ade60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe77ade60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#16 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#17 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f6fe77adec8, data=data@entry=0x7f6fe77adef0) at threads.c:661
#18 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f6fe77adef0) at misc.c:1935
#19 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e620, func=0x7f7019dff420 <really_launch>) at threads.c:704
#20 launch_thread (d=0x149e620) at threads.c:803
#21 0x00007f70198c14d5 in start_thread (arg=0x7f6fe77ae700) at pthread_create.c:465
#22 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 12 (Thread 0x7f700670c700 (LWP 2850)):
#0 0x00007f70181785c6 in __GI___sigsuspend (set=set@entry=0x7f7019d19720 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
#1 0x00007f7019afb65a in GC_suspend_handler_inner (dummy=dummy@entry=0x0, context=context@entry=0x7f700670ad80) at pthread_stop_world.c:322
#2 0x00007f7019afb70f in GC_suspend_handler (sig=30, info=<optimized out>, context=0x7f700670ad80) at pthread_stop_world.c:235
#3 <signal handler called>
#4 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:133
#5 0x00007f70198c3c65 in __GI___pthread_mutex_lock (mutex=0x7f7019d19240 <GC_allocate_ml>) at ../nptl/pthread_mutex_lock.c:80
#6 0x00007f7019af00d9 in GC_generic_malloc_many (lb=lb@entry=128, k=k@entry=0, result=result@entry=0x1530b20) at mallocx.c:308
#7 0x00007f7019af82ce in GC_malloc_kind (bytes=bytes@entry=118, knd=knd@entry=0) at thread_local_alloc.c:178
#8 0x00007f7019aef3e7 in GC_malloc_atomic (lb=lb@entry=118) at malloc.c:284
#9 0x00007f7019da3271 in do_gc_malloc_atomic (what=what@entry=0x7f7019e305f3 "string", size=size@entry=118) at gc-malloc.c:219
#10 scm_gc_malloc_pointerless (size=size@entry=118, what=what@entry=0x7f7019e305f3 "string") at gc-malloc.c:220
#11 0x00007f7019df71c6 in make_stringbuf (len=101) at strings.c:123
#12 scm_i_make_string (len=len@entry=101, charsp=charsp@entry=0x7f700670b5b8, read_only_p=read_only_p@entry=0) at strings.c:290
#13 0x00007f7019df82c7 in scm_string_append (args=("/gnu/store/w3hxb7hrafkhxplcf5qzvsc0fbipqb3i-perl-5.XX.X" "/lib/perl5/5.26.1/TAP/Parser/Result/Unknown.pm")) at strings.c:1395
#14 0x00007f7019e0e17d in vm_regular_engine (thread=0x7f7019d19240 <GC_allocate_ml>, vp=0x144ea20, registers=0x0, resume=428649196) at vm-engine.c:784
#15 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 148fec0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#16 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 148fec0>) at eval.c:481
#17 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 148fec0>) at async.c:400
#18 0x00007f7019e0e17d in vm_regular_engine (thread=0x7f7019d19240 <GC_allocate_ml>, vp=0x144ea20, registers=0x0, resume=428649196) at vm-engine.c:784
#19 0x00007f7019e117da in scm_call_n (proc=#<program 1371940>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#20 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#21 0x00007f7019dff496 in really_launch (d=0x149ec40) at threads.c:794
#22 0x00007f7019d8ec5a in c_body (d=0x7f700670be60) at continuations.c:422
#23 0x00007f7019e0e17d in vm_regular_engine (thread=0x7f7019d19240 <GC_allocate_ml>, vp=0x144ea20, registers=0x0, resume=428649196) at vm-engine.c:784
#24 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 151cf20>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#25 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 151cf20>) at eval.c:481
#26 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 151cf20>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x151cee0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x151cea0) at throw.c:137
#27 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#28 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f700670be60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f700670be60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#29 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f700670be60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f700670be60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#30 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#31 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f700670bec8, data=data@entry=0x7f700670bef0) at threads.c:661
#32 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f700670bef0) at misc.c:1935
#33 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149ec40, func=0x7f7019dff420 <really_launch>) at threads.c:704
#34 launch_thread (d=0x149ec40) at threads.c:803
#35 0x00007f70198c14d5 in start_thread (arg=0x7f700670c700) at pthread_create.c:465
#36 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 11 (Thread 0x7f6fe670c700 (LWP 2857)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x152bca0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x152bc78) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x152bc78, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x152bc78, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x152bc40, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x152bca0, vp=0x144e630, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1526ca0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1526ca0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1526ca0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x152bca0, vp=0x144e630, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371780>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149e360) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f6fe670be60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x152bca0, vp=0x144e630, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 14837e0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 14837e0>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 14837e0>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14836a0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1483640) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe670be60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe670be60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe670be60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe670be60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f6fe670bec8, data=data@entry=0x7f6fe670bef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f6fe670bef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e360, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149e360) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f6fe670c700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 10 (Thread 0x7f70077ae700 (LWP 2848)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e4e64) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e4e38) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e4e38, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e4e38, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e4e00, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4e64, vp=0x144eb40, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1428ac0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1428ac0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1428ac0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4e64, vp=0x144eb40, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 13719c0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x1633040) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f70077ade60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4e64, vp=0x144eb40, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1479360>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1479360>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1479360>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14792e0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14791c0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70077ade60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70077ade60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70077ade60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70077ade60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f70077adec8, data=data@entry=0x7f70077adef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f70077adef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x1633040, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x1633040) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f70077ae700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 9 (Thread 0x7f7015007700 (LWP 2846)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x12713e4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x12713b8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x12713b8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x12713b8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x1271380, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x12713e4, vp=0x144ec60, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1428a00>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1428a00>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1428a00>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x12713e4, vp=0x144ec60, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371a40>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x1633180) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7015006e60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x12713e4, vp=0x144ec60, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1428140>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1428140>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1428140>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14799e0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1479960) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7015006e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7015006e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7015006e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7015006e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7015006ec8, data=data@entry=0x7f7015006ef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7015006ef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x1633180, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x1633180) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7015007700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 8 (Thread 0x7f6fe7fff700 (LWP 2854)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e43e0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e43b8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e43b8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e43b8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e4380, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e43e0, vp=0x144e7e0, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 146faa0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 146faa0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 146faa0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e43e0, vp=0x144e7e0, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371840>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149e740) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f6fe7ffee60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e43e0, vp=0x144e7e0, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 147bd20>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 147bd20>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 147bd20>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x147bb00,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x147baa0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe7ffee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe7ffee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe7ffee60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe7ffee60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f6fe7ffeec8, data=data@entry=0x7f6fe7ffeef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f6fe7ffeef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e740, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149e740) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f6fe7fff700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 7 (Thread 0x7f7004e19700 (LWP 2853)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e45a0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e4578) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e4578, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e4578, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e4540, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e45a0, vp=0x144e870, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 149bf20>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 149bf20>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 149bf20>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e45a0, vp=0x144e870, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371880>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149e880) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7004e18e60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e45a0, vp=0x144e870, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 146fea0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 146fea0>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 146fea0>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x146fe60,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x146fb80) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7004e18e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7004e18e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7004e18e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7004e18e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7004e18ec8, data=data@entry=0x7f7004e18ef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7004e18ef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e880, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149e880) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7004e19700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 6 (Thread 0x7f70168fd700 (LWP 2843)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1271924) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x12718f8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x12718f8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x12718f8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x12718c0, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271924, vp=0x144ee10, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 12b0ac0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 12b0ac0>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 12b0ac0>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271924, vp=0x144ee10, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371b00>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x1633340) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f70168fce60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271924, vp=0x144ee10, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1642fe0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1642fe0>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1642fe0>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1642fc0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1642fa0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70168fce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70168fce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f70168fce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f70168fce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f70168fcec8, data=data@entry=0x7f70168fcef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f70168fcef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x1633340, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x1633340) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f70168fd700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 5 (Thread 0x7f7005ebb700 (LWP 2851)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e4924) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e48f8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e48f8, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e48f8, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e48c0, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4924, vp=0x144e990, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1526f60>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1526f60>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1526f60>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4924, vp=0x144e990, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 1371900>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149ea20) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7005ebae60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4924, vp=0x144e990, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 151ce20>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 151ce20>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 151ce20>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x151cde0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x151cda0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7005ebae60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7005ebae60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7005ebae60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7005ebae60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7005ebaec8, data=data@entry=0x7f7005ebaef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7005ebaef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149ea20, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149ea20) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f7005ebb700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 4 (Thread 0x7f701a292480 (LWP 2838)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1271e60) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129b980, cond=cond@entry=0x1271e38) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x1271e38, mutex=mutex@entry=0x129b980) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x1271e38, mutex=mutex@entry=0x129b980) at threads.c:1621
#4 0x00007f7019e0000b in block_self (queue=((#<smob thread 12a8e90>) #<smob thread 12a8e90>), mutex=mutex@entry=0x129b980, waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e004f0 in timed_wait (c=0x14581e0, current_thread=0x1271e00, current_thread=0x1271e00, waittime=0x0, m=0x129b980, kind=SCM_MUTEX_STANDARD) at threads.c:1347
#6 scm_timed_wait_condition_variable (cond=#<smob condition-variable 1552540>, mutex=#<smob mutex 1552510>, timeout=#<undefined 904>) at threads.c:1440
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271e60, vp=0x1316f30, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=#<program 7f701a0fe030>, argv=argv@entry=0x7ffd630e8c58, nargs=nargs@entry=1) at vm.c:1257
#9 0x00007f7019d95977 in scm_primitive_eval (exp=exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "t.scm") (quit)))) at eval.c:662
#10 0x00007f7019d959d3 in scm_eval (exp=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "t.scm") (quit))),
module_or_state=module_or_state@entry="#<struct module>" = {...}) at eval.c:696
#11 0x00007f7019de0a30 in scm_shell (argc=2, argv=0x7ffd630e92c8) at script.c:454
#12 0x00007f7019dac45d in invoke_main_func (body_data=0x7ffd630e9170) at init.c:340
#13 0x00007f7019d8ec5a in c_body (d=0x7ffd630e90b0) at continuations.c:422
#14 0x00007f7019e0e17d in vm_regular_engine (thread=0x1271e60, vp=0x1316f30, registers=0x0, resume=428636079) at vm-engine.c:784
#15 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1317c80>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#16 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1317c80>) at eval.c:481
#17 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1317c80>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1317c60,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1317c20) at throw.c:137
#18 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#19 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7ffd630e90b0,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7ffd630e90b0,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#20 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7ffd630e90b0,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7ffd630e90b0,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#21 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#22 0x00007f7019dff5bc in with_guile (base=base@entry=0x7ffd630e9118, data=data@entry=0x7ffd630e9140) at threads.c:661
#23 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7ffd630e9140) at misc.c:1935
#24 0x00007f7019dff958 in scm_i_with_guile (dynamic_state=<optimized out>, data=data@entry=0x7ffd630e9140, func=func@entry=0x7f7019dac440 <invoke_main_func>) at threads.c:704
#25 scm_with_guile (func=func@entry=0x7f7019dac440 <invoke_main_func>, data=data@entry=0x7ffd630e9170) at threads.c:710
#26 0x00007f7019dac5f2 in scm_boot_guile (argc=argc@entry=2, argv=argv@entry=0x7ffd630e92c8, main_func=main_func@entry=0x400cc0 <inner_main>, closure=closure@entry=0x0)
at init.c:323
#27 0x0000000000400b60 in main (argc=2, argv=0x7ffd630e92c8) at guile.c:101
Thread 3 (Thread 0x7f700566a700 (LWP 2852)):
#0 0x00007f70198c77af in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x14e4764) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x129bd80, cond=cond@entry=0x14e4738) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x14e4738, mutex=mutex@entry=0x129bd80) at pthread_cond_wait.c:655
#3 0x00007f7019dffe45 in scm_pthread_cond_wait (cond=cond@entry=0x14e4738, mutex=mutex@entry=0x129bd80) at threads.c:1621
#4 0x00007f7019e0000b in block_self (
queue=((#<smob thread 1425d50>) #<smob thread 1404cf0> #<smob thread 1554c70> #<smob thread 1554ff0> #<smob thread 1425db0> #<smob thread 1554de0> #<smob thread 1404a60> #<smob thread 1425e10> #<smob thread 1404fe0> #<smob thread 1425aa0> #<smob thread 1404a00> #<smob thread 1404c20> #<smob thread 1425d50>), mutex=mutex@entry=0x129bd80,
waittime=waittime@entry=0x0) at threads.c:316
#5 0x00007f7019e00157 in lock_mutex (current_thread=0x14e4700, waittime=0x0, m=0x129bd80, kind=SCM_MUTEX_STANDARD) at threads.c:1037
#6 scm_timed_lock_mutex (mutex=#<smob mutex 1552b70>, timeout=<optimized out>) at threads.c:1098
#7 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4764, vp=0x144e900, registers=0x0, resume=428636079) at vm-engine.c:784
#8 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 149bf40>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#9 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 149bf40>) at eval.c:481
#10 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 149bf40>) at async.c:400
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4764, vp=0x144e900, registers=0x0, resume=428636079) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=#<program 13718c0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#14 0x00007f7019dff496 in really_launch (d=0x149e9a0) at threads.c:794
#15 0x00007f7019d8ec5a in c_body (d=0x7f7005669e60) at continuations.c:422
#16 0x00007f7019e0e17d in vm_regular_engine (thread=0x14e4764, vp=0x144e900, registers=0x0, resume=428636079) at vm-engine.c:784
#17 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1428660>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#18 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1428660>) at eval.c:481
#19 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1428660>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1428620,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x14285e0) at throw.c:137
#20 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#21 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7005669e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7005669e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#22 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7005669e60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7005669e60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#23 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#24 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7005669ec8, data=data@entry=0x7f7005669ef0) at threads.c:661
#25 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7005669ef0) at misc.c:1935
#26 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e9a0, func=0x7f7019dff420 <really_launch>) at threads.c:704
#27 launch_thread (d=0x149e9a0) at threads.c:803
#28 0x00007f70198c14d5 in start_thread (arg=0x7f700566a700) at pthread_create.c:465
#29 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 2 (Thread 0x7f7017a70700 (LWP 2841)):
#0 0x00007f70198cad4d in __libc_read (fd=5, buf=buf@entry=0x7f7017a6fa40, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/read.c:26
#1 0x00007f7019d9de57 in read_finalization_pipe_data (data=0x7f7017a6fa40) at finalizers.c:199
#2 0x00007f7019afa663 in GC_do_blocking_inner (data=0x7f7017a6fa00 "@\336\331\031p\177", context=context@entry=0x7f7017a6f640) at pthread_support.c:1299
#3 0x00007f7019aeec3c in GC_with_callee_saves_pushed (fn=0x7f7019afa620 <GC_do_blocking_inner>, arg=arg@entry=0x7f7017a6fa00 "@\336\331\031p\177") at mach_dep.c:303
#4 0x00007f7019af478c in GC_do_blocking (fn=fn@entry=0x7f7019d9de40 <read_finalization_pipe_data>, client_data=client_data@entry=0x7f7017a6fa40) at misc.c:2041
#5 0x00007f7019dff9aa in scm_without_guile (func=0x7f7019d9de40 <read_finalization_pipe_data>, data=0x7f7017a6fa40) at threads.c:722
#6 0x00007f7019d9e207 in finalization_thread_proc (unused=<optimized out>) at finalizers.c:212
#7 0x00007f7019d8ec5a in c_body (d=0x7f7017a6fe60) at continuations.c:422
#8 0x00007f7019e0e17d in vm_regular_engine (thread=0x5, vp=0x144ef30, registers=0x1, resume=428649805) at vm-engine.c:784
#9 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 140d960>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#10 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 140d960>) at eval.c:481
#11 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 140d960>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x140d920,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x140d8e0) at throw.c:137
#12 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#13 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7017a6fe60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7017a6fe60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#14 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f7017a6fe60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f7017a6fe60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#15 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#16 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f7017a6fec8, data=data@entry=0x7f7017a6fef0) at threads.c:661
#17 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f7017a6fef0) at misc.c:1935
#18 0x00007f7019dff958 in scm_i_with_guile (dynamic_state=<optimized out>, data=<optimized out>, func=<optimized out>) at threads.c:704
#19 scm_with_guile (func=<optimized out>, data=<optimized out>) at threads.c:710
#20 0x00007f70198c14d5 in start_thread (arg=0x7f7017a70700) at pthread_create.c:465
#21 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)):
#0 0x00007f7019db0d79 in scm_is_pair (x=<error reading variable: ERROR: Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159
#1 scm_ilength (sx=<optimized out>) at list.c:190
#2 0x00007f7019e0e2f6 in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, registers=0x0, resume=16) at vm-engine.c:909
#3 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1555fe0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#4 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1555fe0>) at eval.c:481
#5 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1555fe0>) at async.c:400
#6 0x00007f7019e0e17d in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, registers=0x0, resume=16) at vm-engine.c:784
#7 0x00007f7019e117da in scm_call_n (proc=#<program 13717c0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#8 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
#9 0x00007f7019dff496 in really_launch (d=0x149e520) at threads.c:794
#10 0x00007f7019d8ec5a in c_body (d=0x7f6fe6f5ce60) at continuations.c:422
#11 0x00007f7019e0e17d in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, registers=0x0, resume=16) at vm-engine.c:784
#12 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<smob catch-closure 1483b20>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
#13 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<smob catch-closure 1483b20>) at eval.c:481
#14 0x00007f7019e009a6 in catch (tag=tag@entry=#t, thunk=#<smob catch-closure 1483b20>,
handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1483ae0,
pre_unwind_handler=<error reading variable: ERROR: Cannot access memory at address 0x100000000>0x1483a80) at throw.c:137
#15 0x00007f7019e00ce5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=<optimized out>, handler=<optimized out>, pre_unwind_handler=<optimized out>) at throw.c:254
#16 0x00007f7019e00e9f in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe6f5ce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe6f5ce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at throw.c:377
#17 0x00007f7019d8f240 in scm_i_with_continuation_barrier (body=body@entry=0x7f7019d8ec50 <c_body>, body_data=body_data@entry=0x7f6fe6f5ce60,
handler=handler@entry=0x7f7019d8eee0 <c_handler>, handler_data=handler_data@entry=0x7f6fe6f5ce60,
pre_unwind_handler=pre_unwind_handler@entry=0x7f7019d8ed40 <pre_unwind_handler>, pre_unwind_handler_data=0x1311bc0) at continuations.c:360
#18 0x00007f7019d8f2d5 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:456
#19 0x00007f7019dff5bc in with_guile (base=base@entry=0x7f6fe6f5cec8, data=data@entry=0x7f6fe6f5cef0) at threads.c:661
#20 0x00007f7019af4758 in GC_call_with_stack_base (fn=fn@entry=0x7f7019dff570 <with_guile>, arg=arg@entry=0x7f6fe6f5cef0) at misc.c:1935
#21 0x00007f7019dfec8d in scm_i_with_guile (dynamic_state=<optimized out>, data=0x149e520, func=0x7f7019dff420 <really_launch>) at threads.c:704
#22 launch_thread (d=0x149e520) at threads.c:803
#23 0x00007f70198c14d5 in start_thread (arg=0x7f6fe6f5d700) at pthread_create.c:465
#24 0x00007f70182342cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--8<---------------cut here---------------end--------------->8---
What this means is that Thread 1 gets NULL instead of a list as its
on-stack argument (vm-engine.c:909 is ‘tail-apply’).
How can arguments on the VM stack be zeroed?
I commented out the MADV_DONTNEED call to be sure, but I can still
reproduce the bug.
Then I thought vp->sp might be out-of-sync compared to the local
variable ‘sp’, which in turn could cause ‘scm_i_vm_mark_stack’ to not
mark a few items on the tip of the stack. So I did this:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 537 bytes --]
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 9509cd643..1136b2271 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -151,7 +151,8 @@
code, or otherwise push anything on the stack, you will need to
CACHE_SP afterwards to restore the possibly-changed stack pointer. */
-#define SYNC_IP() vp->ip = (ip)
+#define SYNC_IP() \
+ do { vp->ip = (ip); vp->sp = (sp); } while (0)
#define CACHE_SP() sp = vp->sp
#define CACHE_REGISTER() \
[-- Attachment #3: Type: text/plain, Size: 2362 bytes --]
That seemed to help but I eventually got another similar crash.
FWIW I managed to reduce (guix build graft) to just the code below, and
it’s enough to trigger a crash after a dozen of runs:
--8<---------------cut here---------------start------------->8---
(define-module (guix build graft)
#:use-module (guix build utils)
#:use-module (rnrs bytevectors)
#:use-module (ice-9 vlist)
#:use-module (ice-9 match)
#:use-module (ice-9 threads)
#:use-module (ice-9 binary-ports)
#:use-module (ice-9 iconv)
#:use-module (srfi srfi-1) ; list library
#:use-module (srfi srfi-26) ; cut and cute
#:export (replace-store-references
rewrite-directory))
(define (exit-on-exception proc)
"Return a procedure that wraps PROC so that 'primitive-exit' is called when
an exception is caught."
(lambda (arg)
(catch #t
(lambda ()
(proc arg))
(const #t)
(lambda (key . args)
;; Since ports are not thread-safe as of Guile 2.0, reopen stderr.
(let ((port (fdopen 2 "w0")))
(print-exception port #f key args)
(display-backtrace (make-stack #t) port)
(dynamic-call "abort" (dynamic-link))
(sleep 1000)
(primitive-exit 1))))))
(define* (rewrite-directory directory output mapping)
(define prefix-len
(string-length directory))
(define (destination file)
(string-append output (string-drop file prefix-len)))
(define (rewrite-leaf file)
(let (#;(stat (lstat file))
(dest (destination file)))
(catch 'foo
(lambda ()
(throw 'foo (dirname (string-append "/tmp/x" dest))))
(lambda (key file)
(call-with-output-string
(lambda (output)
(make-bytevector (expt 2 10) #x77)
(string->bytevector file "UTF-8")
(open-input-string file)
(make-bytevector (expt 2 20) #x77)))))))
(n-par-for-each (pk 'jobs (parallel-job-count))
(exit-on-exception rewrite-leaf)
(find-files directory (const #t)
#:directories? #t)))
;;; graft.scm ends here
--8<---------------cut here---------------end--------------->8---
Thoughts? Whatever ideas you have could be helpful. :-)
Cheers,
Ludo’.
^ permalink raw reply related [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-08 21:55 ` Ludovic Courtès
@ 2018-05-09 0:32 ` Mark H Weaver
2018-05-09 7:17 ` Ludovic Courtès
2018-05-09 9:11 ` Andy Wingo
2018-05-10 15:48 ` bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Mark H Weaver
1 sibling, 2 replies; 23+ messages in thread
From: Mark H Weaver @ 2018-05-09 0:32 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
[...]
> Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)):
> #0 0x00007f7019db0d79 in scm_is_pair (x=<error reading variable: ERROR: Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159
> #1 scm_ilength (sx=<optimized out>) at list.c:190
[...]
> What this means is that Thread 1 gets NULL instead of a list as its
> on-stack argument (vm-engine.c:909 is ‘tail-apply’).
>
> How can arguments on the VM stack be zeroed?
I doubt that's what happened, because I expect that each VM stack is
dedicated to a single hardware thread. In theory, if a single VM stack
is used by one thread, and then later used by another thread,
thread-safety issues on the VM stack could arise in the absense of
proper thread synchronization.
However, I think it's _far_ more likely that the NULL argument on the
stack was copied from memory shared by multiple threads without proper
thread synchronization.
On modern weakly-ordered memory architectures, writes by one thread may
be seen in a different order by another thread. For example, if one
thread allocates a pair, initializes its CAR and CDR to non-NULL values,
and then writes the address of the pair somewhere, another thread could
first read the address of the pair, and then read NULL from its CAR or
CDR, unless proper thread synchronization is used. At best, this
requires memory barriers in both the reader and writer which are
typically quite expensive. On x86 processors the read barrier could
expand into a no-op in typical cases, but the write barrier cannot be
avoided, and must be placed after initializing the structure and before
writing its pointer.
I think it's most likely that something like this is happening, because
NULL is not a valid SCM value. The only code that should normally write
a NULL to an SCM slot is Boehm GC, which clears memory before handing it
to the user. So, if you read a NULL from a memory location that's meant
to hold an SCM, then it's most likely because the reading thread does
not yet see the writes that initialized it, because of the
weakly-ordered memory architecture.
> I commented out the MADV_DONTNEED call to be sure, but I can still
> reproduce the bug.
I strongly doubt that the MADV_DONTNEED is relevant to this issue.
> Then I thought vp->sp might be out-of-sync compared to the local
> variable ‘sp’, which in turn could cause ‘scm_i_vm_mark_stack’ to not
> mark a few items on the tip of the stack. So I did this:
>
> diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
> index 9509cd643..1136b2271 100644
> --- a/libguile/vm-engine.c
> +++ b/libguile/vm-engine.c
> @@ -151,7 +151,8 @@
> code, or otherwise push anything on the stack, you will need to
> CACHE_SP afterwards to restore the possibly-changed stack pointer. */
>
> -#define SYNC_IP() vp->ip = (ip)
> +#define SYNC_IP() \
> + do { vp->ip = (ip); vp->sp = (sp); } while (0)
I don't see how a change like this could be useful for any thread safety
problem. Since stores by one thread may be seen in a different order by
other threads, the memory write corresponding to "vp->sp = (sp)" might
be delayed for some arbitrarily long period of time after the writes
that follow it, up until the next appropriate memory barrier.
For now, I would suggest avoiding multi-threaded code in Guix, or at
least to avoid loading any Scheme code from multiple threads.
How about using multiple processes instead?
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-09 0:32 ` Mark H Weaver
@ 2018-05-09 7:17 ` Ludovic Courtès
2018-05-09 9:11 ` Andy Wingo
1 sibling, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2018-05-09 7:17 UTC (permalink / raw)
To: Mark H Weaver; +Cc: Andy Wingo, 28211
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
> [...]
>> Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)):
>> #0 0x00007f7019db0d79 in scm_is_pair (x=<error reading variable: ERROR: Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159
>> #1 scm_ilength (sx=<optimized out>) at list.c:190
> [...]
>> What this means is that Thread 1 gets NULL instead of a list as its
>> on-stack argument (vm-engine.c:909 is ‘tail-apply’).
>>
>> How can arguments on the VM stack be zeroed?
>
> I doubt that's what happened, because I expect that each VM stack is
> dedicated to a single hardware thread. In theory, if a single VM stack
> is used by one thread, and then later used by another thread,
> thread-safety issues on the VM stack could arise in the absense of
> proper thread synchronization.
>
> However, I think it's _far_ more likely that the NULL argument on the
> stack was copied from memory shared by multiple threads without proper
> thread synchronization.
It could be this, but this particular case is an “embarrassingly
parallel” program where threads work on independent data sets without
any inter-thread communication whatsoever.
What you describe could nevertheless be happening at a lower level,
within libguile, though it’s not clear to me where that could be.
>> I commented out the MADV_DONTNEED call to be sure, but I can still
>> reproduce the bug.
>
> I strongly doubt that the MADV_DONTNEED is relevant to this issue.
I thought about it because that’s one way part of the VM stack could be
zeroed out.
>> Then I thought vp->sp might be out-of-sync compared to the local
>> variable ‘sp’, which in turn could cause ‘scm_i_vm_mark_stack’ to not
>> mark a few items on the tip of the stack. So I did this:
>>
>> diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
>> index 9509cd643..1136b2271 100644
>> --- a/libguile/vm-engine.c
>> +++ b/libguile/vm-engine.c
>> @@ -151,7 +151,8 @@
>> code, or otherwise push anything on the stack, you will need to
>> CACHE_SP afterwards to restore the possibly-changed stack pointer. */
>>
>> -#define SYNC_IP() vp->ip = (ip)
>> +#define SYNC_IP() \
>> + do { vp->ip = (ip); vp->sp = (sp); } while (0)
>
> I don't see how a change like this could be useful for any thread safety
> problem.
I witnessed situations where the local ‘sp’ seemed to be different from
‘vp->sp’, though it’s hard to tell because I’m unsure where gcc stores
‘sp’. Here’s an example:
--8<---------------cut here---------------start------------->8---
(gdb) frame
#16 0x00007fabf30af2ca in vm_regular_engine (thread=0x24e6000, vp=0x22de6c0, registers=0x0, resume=40) at vm-engine.c:785
785 ret = scm_apply_subr (sp, FRAME_LOCALS_COUNT ());
(gdb) p vp->sp
$5 = (union scm_vm_stack_element *) 0x7fabec158718
(gdb) p (union scm_vm_stack_element *) $r13
$6 = (union scm_vm_stack_element *) 0x7fabec158e30
(gdb) p $6 - $5
$7 = 227
(gdb) p vp->fp
$8 = (union scm_vm_stack_element *) 0x7fabec158730
(gdb) p vp->stack_top
$9 = (union scm_vm_stack_element *) 0x7fabec159000
(gdb) p vp->stack_bottom
$10 = (union scm_vm_stack_element *) 0x7fabec158000
(gdb) p vp->sp_min_since_gc
$11 = (union scm_vm_stack_element *) 0x7fabec158620
(gdb) info registers
rax 0x1 1
rbx 0xa 10
rcx 0x28 40
rdx 0x0 0
rsi 0x23f1920 37689632
rdi 0x24e6000 38690816
rbp 0x22de6c0 0x22de6c0
rsp 0x7fabcce18660 0x7fabcce18660
r8 0x1 1
r9 0x1 1
r10 0x100 256
r11 0x23f1920 37689632
r12 0x7fabf330b8c0 140376496191680
r13 0x7fabec158e30 140376376970800
r14 0x7fabf30c6d7c 140376493813116
r15 0x7fabf0fa7f28 140376459083560
rip 0x7fabf30af2ca 0x7fabf30af2ca <vm_regular_engine+14058>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
--8<---------------cut here---------------end--------------->8---
My hypothesis was that such a bug could lead heap elements to be
reclaimed too early. This is more likely to happen in a multi-threaded
context because one thread could be allocating memory and triggering a
GC while another thread is invoking a subr with an out-of-sync ‘vp->sp’.
Does that make sense?
> For now, I would suggest avoiding multi-threaded code in Guix, or at
> least to avoid loading any Scheme code from multiple threads.
>
> How about using multiple processes instead?
We could do that, but with my Guile maintainer hat on (a hat I don’t
wear that often as you might have noticed ;-)) I think it would be nice
to fix the issue.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-09 0:32 ` Mark H Weaver
2018-05-09 7:17 ` Ludovic Courtès
@ 2018-05-09 9:11 ` Andy Wingo
2018-05-10 6:50 ` Mark H Weaver
1 sibling, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2018-05-09 9:11 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 28211
On Wed 09 May 2018 02:32, Mark H Weaver <mhw@netris.org> writes:
> However, I think it's _far_ more likely that the NULL argument on the
> stack was copied from memory shared by multiple threads without proper
> thread synchronization.
I think this is unlikely on x86 given its total-store-ordering memory
model. I agree with you about the value of barriers, but I don't think
they are part of this bug that Ludo is seeing.
>> I commented out the MADV_DONTNEED call to be sure, but I can still
>> reproduce the bug.
>
> I strongly doubt that the MADV_DONTNEED is relevant to this issue.
It could be. It would zero out VM stack frames, and if GC is called
when/if vp->sp is out of date, then that would be possible. However I
think vp->sp is never out of date, so that's probably not it. The
things that can be out of date are the on-heap copy of the IP (vp->ip)
and the local register copy of the sp (sp). It's more likely for the
local "sp" cache to be out of date -- if we recursed through Scheme in a
call out from the VM, eventualy causing stack expansion and relocation,
then on the return forgot to re-cache the sp value, that could be it.
Similarly, forgetting to set vp->ip before calling out to something that
could GC could likewise cause a problem because the stack map wouldn't
be right and the precise stack marker could clear a value by mistake.
This only happens for non-innermost frames though; the innermost frame
is marked conservatively.
The rules are: update vp->ip before something that can allocate, and
update local "sp" after returning from a C function that could have
recursively called Scheme.
I did find a couple places in the VM where we forgot to do one of these,
e.g. 07b7490f73fb4a6cb0c9577d082d37c8d9cee7b0 and just now
9a72e212622fa3bd118d7c02c4386601285b3224. These two patches aren't
shipped yet fwiw.
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-09 9:11 ` Andy Wingo
@ 2018-05-10 6:50 ` Mark H Weaver
2018-05-10 7:53 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Mark H Weaver @ 2018-05-10 6:50 UTC (permalink / raw)
To: Andy Wingo; +Cc: 28211
Hi Andy,
Andy Wingo <wingo@igalia.com> writes:
> On Wed 09 May 2018 02:32, Mark H Weaver <mhw@netris.org> writes:
>
>> However, I think it's _far_ more likely that the NULL argument on the
>> stack was copied from memory shared by multiple threads without proper
>> thread synchronization.
>
> I think this is unlikely on x86 given its total-store-ordering memory
> model. I agree with you about the value of barriers, but I don't think
> they are part of this bug that Ludo is seeing.
I think you're forgetting about the C compiler. It's true that x86
machine code has a TSO memory model, but C does not. In the absence of
barriers, the C compiler may freely reorder stores to non-volatile,
non-atomic objects. In particular, it is free to reorder the
initialization of an object with the write of that object's address.
I admit that I haven't checked whether GCC 5.5.0 does this in practice.
Do you have reason to believe that it never does so?
Thanks,
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-10 6:50 ` Mark H Weaver
@ 2018-05-10 7:53 ` Andy Wingo
2018-06-29 15:03 ` bug#28211: Stack marking issue in multi-threaded code Ludovic Courtès
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2018-05-10 7:53 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 28211
On Thu 10 May 2018 08:50, Mark H Weaver <mhw@netris.org> writes:
> Andy Wingo <wingo@igalia.com> writes:
>
>> On Wed 09 May 2018 02:32, Mark H Weaver <mhw@netris.org> writes:
>>
>>> However, I think it's _far_ more likely that the NULL argument on the
>>> stack was copied from memory shared by multiple threads without proper
>>> thread synchronization.
>>
>> I think this is unlikely on x86 given its total-store-ordering memory
>> model. I agree with you about the value of barriers, but I don't think
>> they are part of this bug that Ludo is seeing.
>
> I think you're forgetting about the C compiler. It's true that x86
> machine code has a TSO memory model, but C does not. In the absence of
> barriers, the C compiler may freely reorder stores to non-volatile,
> non-atomic objects. In particular, it is free to reorder the
> initialization of an object with the write of that object's address.
>
> I admit that I haven't checked whether GCC 5.5.0 does this in practice.
> Do you have reason to believe that it never does so?
Oh I agree with you here as well, and compiler reordering could well be
happening here. My suspicions are however that it's not happening. In
libguile, we rarely mutate shared state, and in that case it's usually
within mutexes. The main source of mutation in libguile is
initialization -- but there that's on a fresh object local to a thread,
and we try to avoid publishing that object to other threads without a
barrier (atomic or mutex), and in any case such publishing is usually
outside of the region that a compiler can work on.
There is the possibility of mutation via e.g. vector-set!, but hopefully
we aren't doing that on shared data; likewise in Scheme there are
barriers (the atomic box instructions and mutexes, both of which are
compiler barriers as well). It's still possible to write Scheme
programs with races, of course, but I don't think that's what's
happening here.
I could be misunderstanding things of course!
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-08 21:55 ` Ludovic Courtès
2018-05-09 0:32 ` Mark H Weaver
@ 2018-05-10 15:48 ` Mark H Weaver
2018-05-10 16:01 ` Mark H Weaver
1 sibling, 1 reply; 23+ messages in thread
From: Mark H Weaver @ 2018-05-10 15:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Hi,
I've been studying the backtrace provided by Ludovic, trying to
determine where, in the Scheme code, this error happened in thread 1.
ludo@gnu.org (Ludovic Courtès) writes:
> Thread 1 (Thread 0x7f6fe6f5d700 (LWP 2856)):
> #0 0x00007f7019db0d79 in scm_is_pair (x=<error reading variable: ERROR: Cannot access memory at address 0x0>0x0) at ../libguile/pairs.h:159
> #1 scm_ilength (sx=<optimized out>) at list.c:190
> #2 0x00007f7019e0e2f6 in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, registers=0x0, resume=16) at vm-engine.c:909
> #3 0x00007f7019e117da in scm_call_n (proc=proc@entry=#<program 1555fe0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
> #4 0x00007f7019d94879 in scm_call_0 (proc=proc@entry=#<program 1555fe0>) at eval.c:481
> #5 0x00007f7019d85eb8 in scm_call_with_unblocked_asyncs (proc=#<program 1555fe0>) at async.c:400
> #6 0x00007f7019e0e17d in vm_regular_engine (thread=0x1425670, vp=0x144e6c0, registers=0x0, resume=16) at vm-engine.c:784
> #7 0x00007f7019e117da in scm_call_n (proc=#<program 13717c0>, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1257
> #8 0x00007f7019d94879 in scm_call_0 (proc=<optimized out>) at eval.c:481
> #9 0x00007f7019dff496 in really_launch (d=0x149e520) at threads.c:794
The call to 'scm_call_with_unblocked_asyncs' in frame #5 is an important
clue, because it is used in very few places. I see only two such places
in Guile (and none in Guix):
https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/scm-style-repl.scm?h=v2.2.3#n80
https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n158
I assume that it must be the second one in this case. So, I believe
frames 5-9 correspond to lines 147 through 158 of ice-9/threads.scm:
https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n147
which is within 'call-with-new-thread', called via the 'begin-thread'
macro used by 'n-par-for-each', here:
https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n320
However, I would expect to see a 'catch' frame deeper in the stack,
since the procedure passed to 'n-par-for-each' by graft.scm is wrapped
by 'exit-on-exception'.
From these facts, I believe we can conclude that the error is happening
within the body of 'begin-thread' in 'n-par-for-each', but outside of
the body of 'proc' passed to 'n-par-for-each'.
There's not a lot of code in there. My best guess at the moment is that
this error is happening within the (apply proc args) on line 335,
although I do not yet have an explanation of how that could happen.
To be continued...
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2018-05-10 15:48 ` bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Mark H Weaver
@ 2018-05-10 16:01 ` Mark H Weaver
0 siblings, 0 replies; 23+ messages in thread
From: Mark H Weaver @ 2018-05-10 16:01 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Mark H Weaver <mhw@netris.org> writes:
> From these facts, I believe we can conclude that the error is happening
> within the body of 'begin-thread' in 'n-par-for-each', but outside of
> the body of 'proc' passed to 'n-par-for-each'.
It could also be happening within the 'call-with-backtrace', used here:
https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/threads.scm?h=v2.2.3#n159
More investigation is needed, but it's unlikely that I'll be able to
spend more time on this today.
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-05-10 7:53 ` Andy Wingo
@ 2018-06-29 15:03 ` Ludovic Courtès
2018-06-29 16:54 ` Mark H Weaver
2020-03-12 21:59 ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès
0 siblings, 2 replies; 23+ messages in thread
From: Ludovic Courtès @ 2018-06-29 15:03 UTC (permalink / raw)
To: Andy Wingo; +Cc: 28211
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
Hey hey, comrades!
I have a fix for some (most?) of the crashes we were seeing while
running multi-threaded code such as (guix build compile), and,
presumably, the grafting code mentioned at the beginning of this bug
report, although I haven’t checked yet.
So, ‘scm_i_vm_mark_stack’ marks the stack precisely, but contrary to
what I suspected, precise marking is not at fault.
Instead, the problem has to do with the fact that some VM instructions
change the frame pointer (vp->fp) before they have set up the dynamic
link for that new frame.
As a consequence, if a stop-the-world GC is triggered after vp->fp has
been changed and before its dynamic link has been set, the stack-walking
loop in ‘scm_i_vm_mark_stack’ could stop very early, leaving a lot of
objects unmarked.
The patch below fixes the problem for me. \o/
I’m thinking we could perhaps add a compiler barrier before ‘vp->fp = new_fp’
statements, but in practice it’s not necessary here (x86_64, gcc 7).
Thoughts?
I’d like to push this real soon. I’ll also do more testing on real
workloads from Guix, and then I’d like to release 2.2.4, hopefully
within a few days.
Thank you and thanks Andy for the discussions on IRC!
Ludo’, who’s going to party all night long. :-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3257 bytes --]
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 1aa4e9699..19ff3e498 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -548,7 +548,7 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
VM_DEFINE_OP (1, call, "call", OP2 (X8_F24, X8_C24))
{
scm_t_uint32 proc, nlocals;
- union scm_vm_stack_element *old_fp;
+ union scm_vm_stack_element *old_fp, *new_fp;
UNPACK_24 (op, proc);
UNPACK_24 (ip[1], nlocals);
@@ -556,9 +556,10 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
PUSH_CONTINUATION_HOOK ();
old_fp = vp->fp;
- vp->fp = SCM_FRAME_SLOT (old_fp, proc - 1);
- SCM_FRAME_SET_DYNAMIC_LINK (vp->fp, old_fp);
- SCM_FRAME_SET_RETURN_ADDRESS (vp->fp, ip + 2);
+ new_fp = SCM_FRAME_SLOT (old_fp, proc - 1);
+ SCM_FRAME_SET_DYNAMIC_LINK (new_fp, old_fp);
+ SCM_FRAME_SET_RETURN_ADDRESS (new_fp, ip + 2);
+ vp->fp = new_fp;
RESET_FRAME (nlocals);
@@ -586,7 +587,7 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
{
scm_t_uint32 proc, nlocals;
scm_t_int32 label;
- union scm_vm_stack_element *old_fp;
+ union scm_vm_stack_element *old_fp, *new_fp;
UNPACK_24 (op, proc);
UNPACK_24 (ip[1], nlocals);
@@ -595,9 +596,10 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
PUSH_CONTINUATION_HOOK ();
old_fp = vp->fp;
- vp->fp = SCM_FRAME_SLOT (old_fp, proc - 1);
- SCM_FRAME_SET_DYNAMIC_LINK (vp->fp, old_fp);
- SCM_FRAME_SET_RETURN_ADDRESS (vp->fp, ip + 3);
+ new_fp = SCM_FRAME_SLOT (old_fp, proc - 1);
+ SCM_FRAME_SET_DYNAMIC_LINK (new_fp, old_fp);
+ SCM_FRAME_SET_RETURN_ADDRESS (new_fp, ip + 3);
+ vp->fp = new_fp;
RESET_FRAME (nlocals);
@@ -3893,7 +3895,7 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
NEXT (1);
{
- union scm_vm_stack_element *old_fp;
+ union scm_vm_stack_element *old_fp, *new_fp;
size_t old_frame_size = FRAME_LOCALS_COUNT ();
SCM proc = scm_i_async_pop (thread);
@@ -3907,9 +3909,10 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
handle-interrupts opcode to handle any additional
interrupts. */
old_fp = vp->fp;
- vp->fp = SCM_FRAME_SLOT (old_fp, old_frame_size + 1);
- SCM_FRAME_SET_DYNAMIC_LINK (vp->fp, old_fp);
- SCM_FRAME_SET_RETURN_ADDRESS (vp->fp, ip);
+ new_fp = SCM_FRAME_SLOT (old_fp, old_frame_size + 1);
+ SCM_FRAME_SET_DYNAMIC_LINK (new_fp, old_fp);
+ SCM_FRAME_SET_RETURN_ADDRESS (new_fp, ip);
+ vp->fp = new_fp;
SP_SET (0, proc);
diff --git a/libguile/vm.c b/libguile/vm.c
index c8ec6e1b2..7749159e5 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -1011,6 +1011,18 @@ scm_i_vm_mark_stack (struct scm_vm *vp, struct GC_ms_entry *mark_stack_ptr,
slot_map = find_slot_map (SCM_FRAME_RETURN_ADDRESS (fp), &cache);
}
+ size_t extra = 0;
+ for (; sp < vp->stack_top; sp++)
+ {
+ if (GC_is_heap_ptr (sp->as_ptr))
+ extra++;
+ }
+ if (extra)
+ {
+ printf ("%s extra: %zi\n", __func__, extra);
+ abort ();
+ }
+
return_unused_stack_to_os (vp);
return mark_stack_ptr;
^ permalink raw reply related [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-29 15:03 ` bug#28211: Stack marking issue in multi-threaded code Ludovic Courtès
@ 2018-06-29 16:54 ` Mark H Weaver
2018-06-29 21:18 ` Ludovic Courtès
2020-03-12 21:59 ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès
1 sibling, 1 reply; 23+ messages in thread
From: Mark H Weaver @ 2018-06-29 16:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
> I have a fix for some (most?) of the crashes we were seeing while
> running multi-threaded code such as (guix build compile), and,
> presumably, the grafting code mentioned at the beginning of this bug
> report, although I haven’t checked yet.
>
> So, ‘scm_i_vm_mark_stack’ marks the stack precisely, but contrary to
> what I suspected, precise marking is not at fault.
>
> Instead, the problem has to do with the fact that some VM instructions
> change the frame pointer (vp->fp) before they have set up the dynamic
> link for that new frame.
>
> As a consequence, if a stop-the-world GC is triggered after vp->fp has
> been changed and before its dynamic link has been set, the stack-walking
> loop in ‘scm_i_vm_mark_stack’ could stop very early, leaving a lot of
> objects unmarked.
>
> The patch below fixes the problem for me. \o/
That's great news! Thanks for investigating.
> I’m thinking we could perhaps add a compiler barrier before ‘vp->fp = new_fp’
> statements, but in practice it’s not necessary here (x86_64, gcc 7).
>
> Thoughts?
Indeed, we need something to ensure that the compiler won't reorder
these writes. My recommendation would be to use the 'volatile'
qualifier in the declarations of both the 'fp' field of 'struct scm_vm'
and the stack element modified by SCM_FRAME_SET_DYNAMIC_LINK.
Maybe something like this:
--8<---------------cut here---------------start------------->8---
diff --git a/libguile/frames.h b/libguile/frames.h
index ef2db3df5..8554f886b 100644
--- a/libguile/frames.h
+++ b/libguile/frames.h
@@ -89,6 +89,7 @@
union scm_vm_stack_element
{
scm_t_uintptr as_uint;
+ volatile scm_t_uintptr as_volatile_uint;
scm_t_uint32 *as_ip;
SCM as_scm;
double as_f64;
@@ -104,7 +105,7 @@ union scm_vm_stack_element
#define SCM_FRAME_RETURN_ADDRESS(fp) ((fp)[0].as_ip)
#define SCM_FRAME_SET_RETURN_ADDRESS(fp, ra) ((fp)[0].as_ip = (ra))
#define SCM_FRAME_DYNAMIC_LINK(fp) ((fp) + (fp)[1].as_uint)
-#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_uint = ((dl) - (fp)))
+#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_volatile_uint = ((dl) - (fp)))
#define SCM_FRAME_SLOT(fp,i) ((fp) - (i) - 1)
#define SCM_FRAME_LOCAL(fp,i) (SCM_FRAME_SLOT (fp, i)->as_scm)
#define SCM_FRAME_NUM_LOCALS(fp, sp) ((fp) - (sp))
diff --git a/libguile/vm.h b/libguile/vm.h
index a1cac391f..0a6179c19 100644
--- a/libguile/vm.h
+++ b/libguile/vm.h
@@ -38,7 +38,7 @@ enum {
struct scm_vm {
scm_t_uint32 *ip; /* instruction pointer */
union scm_vm_stack_element *sp; /* stack pointer */
- union scm_vm_stack_element *fp; /* frame pointer */
+ union scm_vm_stack_element *volatile fp; /* frame pointer */
union scm_vm_stack_element *stack_limit; /* stack limit address */
int trace_level; /* traces enabled if trace_level > 0 */
union scm_vm_stack_element *sp_min_since_gc; /* deepest sp since last gc */
--8<---------------cut here---------------end--------------->8---
> I’d like to push this real soon. I’ll also do more testing on real
> workloads from Guix, and then I’d like to release 2.2.4, hopefully
> within a few days.
Sounds good to me.
Thanks,
Mark
^ permalink raw reply related [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-29 16:54 ` Mark H Weaver
@ 2018-06-29 21:18 ` Ludovic Courtès
2018-06-29 23:18 ` Mark H Weaver
0 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2018-06-29 21:18 UTC (permalink / raw)
To: Mark H Weaver; +Cc: Andy Wingo, 28211
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
[...]
>> I’m thinking we could perhaps add a compiler barrier before ‘vp->fp = new_fp’
>> statements, but in practice it’s not necessary here (x86_64, gcc 7).
>>
>> Thoughts?
I just pushed the patch as 23af45e248e8e2bec99c712842bf24d6661abbe2.
> Indeed, we need something to ensure that the compiler won't reorder
> these writes. My recommendation would be to use the 'volatile'
> qualifier in the declarations of both the 'fp' field of 'struct scm_vm'
> and the stack element modified by SCM_FRAME_SET_DYNAMIC_LINK.
>
> Maybe something like this:
>
> diff --git a/libguile/frames.h b/libguile/frames.h
> index ef2db3df5..8554f886b 100644
> --- a/libguile/frames.h
> +++ b/libguile/frames.h
> @@ -89,6 +89,7 @@
> union scm_vm_stack_element
> {
> scm_t_uintptr as_uint;
> + volatile scm_t_uintptr as_volatile_uint;
[...]
> +#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_volatile_uint = ((dl) - (fp)))
I’m not sure this is exactly what we need.
What I had in mind, to make sure the vp->fp assignment really happens
after the SCM_FRAME_SET_DYNAMIC_LINK, was to do something like this:
SCM_FRAME_SET_RETURN_ADDRESS (new_fp, …);
SCM_FRAME_SET_DYNAMIC_LINK (new_fp, …);
asm volatile ("" : : : "memory");
vp->fp = new_fp;
I think that more accurately reflects what we want, WDYT?
It’s GCC-specific though (I don’t think Clang implements ‘asm’ in a
compatible way, does it?) and I suppose we’d have to ignore the non-GCC
case.
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-29 21:18 ` Ludovic Courtès
@ 2018-06-29 23:18 ` Mark H Weaver
2018-06-30 20:53 ` Ludovic Courtès
0 siblings, 1 reply; 23+ messages in thread
From: Mark H Weaver @ 2018-06-29 23:18 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> I’m thinking we could perhaps add a compiler barrier before ‘vp->fp = new_fp’
>>> statements, but in practice it’s not necessary here (x86_64, gcc 7).
>>>
>>> Thoughts?
>
> I just pushed the patch as 23af45e248e8e2bec99c712842bf24d6661abbe2.
>
>> Indeed, we need something to ensure that the compiler won't reorder
>> these writes. My recommendation would be to use the 'volatile'
>> qualifier in the declarations of both the 'fp' field of 'struct scm_vm'
>> and the stack element modified by SCM_FRAME_SET_DYNAMIC_LINK.
>>
>> Maybe something like this:
>>
>> diff --git a/libguile/frames.h b/libguile/frames.h
>> index ef2db3df5..8554f886b 100644
>> --- a/libguile/frames.h
>> +++ b/libguile/frames.h
>> @@ -89,6 +89,7 @@
>> union scm_vm_stack_element
>> {
>> scm_t_uintptr as_uint;
>> + volatile scm_t_uintptr as_volatile_uint;
>
> [...]
>
>> +#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_volatile_uint = ((dl) - (fp)))
>
> I’m not sure this is exactly what we need.
>
> What I had in mind, to make sure the vp->fp assignment really happens
> after the SCM_FRAME_SET_DYNAMIC_LINK, was to do something like this:
>
> SCM_FRAME_SET_RETURN_ADDRESS (new_fp, …);
> SCM_FRAME_SET_DYNAMIC_LINK (new_fp, …);
>
> asm volatile ("" : : : "memory");
>
> vp->fp = new_fp;
>
> I think that more accurately reflects what we want, WDYT?
>
> It’s GCC-specific though (I don’t think Clang implements ‘asm’ in a
> compatible way, does it?) and I suppose we’d have to ignore the non-GCC
> case.
Right, the problem is that the "asm volatile" solution is not portable.
To my mind, it's fine to optionally use GCC extensions for improved
performance, but I think we should ensure that Guile works reliably when
compiled with any conforming C compiler.
What problem do you see with my proposed portable solution? If I
understand C99 section 5.1.2.3 paragraph 2 correctly, compilers are not
permitted to reorder accesses to volatile objects as long as there is a
sequence point between them.
I should say that I'm not confident that _either_ of these proposed
solutions will adequately address all of the possible problems that
could occur when GC is performed on VM threads stopped at arbitrary
points in their execution.
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-29 23:18 ` Mark H Weaver
@ 2018-06-30 20:53 ` Ludovic Courtès
2018-06-30 21:49 ` Mark H Weaver
0 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2018-06-30 20:53 UTC (permalink / raw)
To: Mark H Weaver; +Cc: Andy Wingo, 28211
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
[...]
>>> Indeed, we need something to ensure that the compiler won't reorder
>>> these writes. My recommendation would be to use the 'volatile'
>>> qualifier in the declarations of both the 'fp' field of 'struct scm_vm'
>>> and the stack element modified by SCM_FRAME_SET_DYNAMIC_LINK.
>>>
>>> Maybe something like this:
>>>
>>> diff --git a/libguile/frames.h b/libguile/frames.h
>>> index ef2db3df5..8554f886b 100644
>>> --- a/libguile/frames.h
>>> +++ b/libguile/frames.h
>>> @@ -89,6 +89,7 @@
>>> union scm_vm_stack_element
>>> {
>>> scm_t_uintptr as_uint;
>>> + volatile scm_t_uintptr as_volatile_uint;
>>
>> [...]
>>
>>> +#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_volatile_uint = ((dl) - (fp)))
>>
>> I’m not sure this is exactly what we need.
>>
>> What I had in mind, to make sure the vp->fp assignment really happens
>> after the SCM_FRAME_SET_DYNAMIC_LINK, was to do something like this:
>>
>> SCM_FRAME_SET_RETURN_ADDRESS (new_fp, …);
>> SCM_FRAME_SET_DYNAMIC_LINK (new_fp, …);
>>
>> asm volatile ("" : : : "memory");
>>
>> vp->fp = new_fp;
>>
>> I think that more accurately reflects what we want, WDYT?
>>
>> It’s GCC-specific though (I don’t think Clang implements ‘asm’ in a
>> compatible way, does it?) and I suppose we’d have to ignore the non-GCC
>> case.
>
> Right, the problem is that the "asm volatile" solution is not portable.
>
> To my mind, it's fine to optionally use GCC extensions for improved
> performance, but I think we should ensure that Guile works reliably when
> compiled with any conforming C compiler.
I agree, of course (that said, most compilers implement most GCC
extensions nowadays, but ‘asm’ is probably an exception).
> What problem do you see with my proposed portable solution? If I
> understand C99 section 5.1.2.3 paragraph 2 correctly, compilers are not
> permitted to reorder accesses to volatile objects as long as there is a
> sequence point between them.
My understand is that what you propose is (almost*) equivalent to the
asm trick, provided SCM_FRAME_SET_DYNAMIC_LINK is the last statement
before the vp->fp assignment. So we’d have to make sure we keep things
in this order, right?
[*] The ‘volatile’ qualifier on the field does more than just an
instruction reordering barrier: AIUI, it forces the compiler to emit
a load and store instruction right at the assignment point, which is
a stricter constraint than what we need, I think.
> I should say that I'm not confident that _either_ of these proposed
> solutions will adequately address all of the possible problems that
> could occur when GC is performed on VM threads stopped at arbitrary
> points in their execution.
Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
that each stack is marked by the thread it belongs to, in terms of data
locality, and thus also in terms of being sure that vp->fp is up-to-date
when the marker reads it. It’s not something we can change now, though.
Alternately, we could use atomics when accessing vp->fp to ensure memory
consistency (I tried that during my debugging journey…). It could be
costly.
Anyway, I don’t think we’ll have the final word on all this before
2.2.4. The way I see it we should keep working on improving it, but
there are difficult choices to make, so it will probably take a bit of
time.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-30 20:53 ` Ludovic Courtès
@ 2018-06-30 21:49 ` Mark H Weaver
2018-07-01 10:12 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Mark H Weaver @ 2018-06-30 21:49 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andy Wingo, 28211
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>>> Indeed, we need something to ensure that the compiler won't reorder
>>>> these writes. My recommendation would be to use the 'volatile'
>>>> qualifier in the declarations of both the 'fp' field of 'struct scm_vm'
>>>> and the stack element modified by SCM_FRAME_SET_DYNAMIC_LINK.
>>>>
>>>> Maybe something like this:
>>>>
>>>> diff --git a/libguile/frames.h b/libguile/frames.h
>>>> index ef2db3df5..8554f886b 100644
>>>> --- a/libguile/frames.h
>>>> +++ b/libguile/frames.h
>>>> @@ -89,6 +89,7 @@
>>>> union scm_vm_stack_element
>>>> {
>>>> scm_t_uintptr as_uint;
>>>> + volatile scm_t_uintptr as_volatile_uint;
>>>
>>> [...]
>>>
>>>> +#define SCM_FRAME_SET_DYNAMIC_LINK(fp, dl) ((fp)[1].as_volatile_uint = ((dl) - (fp)))
>>>
>>> I’m not sure this is exactly what we need.
>>>
>>> What I had in mind, to make sure the vp->fp assignment really happens
>>> after the SCM_FRAME_SET_DYNAMIC_LINK, was to do something like this:
>>>
>>> SCM_FRAME_SET_RETURN_ADDRESS (new_fp, …);
>>> SCM_FRAME_SET_DYNAMIC_LINK (new_fp, …);
>>>
>>> asm volatile ("" : : : "memory");
>>>
>>> vp->fp = new_fp;
>>>
>>> I think that more accurately reflects what we want, WDYT?
>>>
>>> It’s GCC-specific though (I don’t think Clang implements ‘asm’ in a
>>> compatible way, does it?) and I suppose we’d have to ignore the non-GCC
>>> case.
>>
>> Right, the problem is that the "asm volatile" solution is not portable.
>>
>> To my mind, it's fine to optionally use GCC extensions for improved
>> performance, but I think we should ensure that Guile works reliably when
>> compiled with any conforming C compiler.
>
> I agree, of course (that said, most compilers implement most GCC
> extensions nowadays, but ‘asm’ is probably an exception).
>
>> What problem do you see with my proposed portable solution? If I
>> understand C99 section 5.1.2.3 paragraph 2 correctly, compilers are not
>> permitted to reorder accesses to volatile objects as long as there is a
>> sequence point between them.
>
> My understand is that what you propose is (almost*) equivalent to the
> asm trick, provided SCM_FRAME_SET_DYNAMIC_LINK is the last statement
> before the vp->fp assignment. So we’d have to make sure we keep things
> in this order, right?
I don't think it matters. This would only ensure the relative ordering
of the SCM_FRAME_SET_DYNAMIC_LINK and the vp->fp assignment. IIUC, the
non-volatile memory accesses could be reordered relative to either of
them.
The "asm volatile" memory barrier would be stronger, guaranteeing that
_all_ accesses before the barrier would be performed before _all_
accessed after the barrier, within that thread.
> [*] The ‘volatile’ qualifier on the field does more than just an
> instruction reordering barrier: AIUI, it forces the compiler to emit
> a load and store instruction right at the assignment point, which is
> a stricter constraint than what we need, I think.
I'm not sure what "right at the assignment point" means exactly, given
that the compiler is free to reorder things quite a bit.
In addition to the C99 standard which I cited in my previous email, you
might also find the following link informative:
https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html
In particular:
[...] The minimum requirement is that at a sequence point all
previous accesses to volatile objects have stabilized and no
subsequent accesses have occurred. Thus an implementation is free to
reorder and combine volatile accesses that occur between sequence
points, but cannot do so for accesses across a sequence point. The
use of volatile does not allow you to violate the restriction on
updating objects multiple times between two sequence points.
Accesses to non-volatile objects are not ordered with respect to
volatile accesses. You cannot use a volatile object as a memory
barrier to order a sequence of writes to non-volatile memory. For
instance:
int *ptr = something;
volatile int vobj;
*ptr = something;
vobj = 1;
Unless *ptr and vobj can be aliased, it is not guaranteed that the
write to *ptr occurs by the time the update of vobj happens. If you
need this guarantee, you must use a stronger memory barrier [...]
>> I should say that I'm not confident that _either_ of these proposed
>> solutions will adequately address all of the possible problems that
>> could occur when GC is performed on VM threads stopped at arbitrary
>> points in their execution.
>
> Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
> that each stack is marked by the thread it belongs to, in terms of data
> locality, and thus also in terms of being sure that vp->fp is up-to-date
> when the marker reads it. It’s not something we can change now, though.
I'm not sure it matters what thread the marking is done in, because when
the actual collection happens, all threads are first stopped in their
signal handlers, and presumably the appropriate memory barriers are
performed so that all threads are synchronized before the full
collection.
Now, I'm aware that libgc does incremental marking as well, but I'm
optimistically hoping that they've done their homework to ensure that if
anything might have changed between the incremental marking and the full
collection, that the relevant objects will be marked again before the
full collection. However, I admit that I don't know enough of libgc
internals to know if this is really the case.
What do you think?
> Alternately, we could use atomics when accessing vp->fp to ensure memory
> consistency (I tried that during my debugging journey…). It could be
> costly.
This would be far too costly to consider, in my opinion.
> Anyway, I don’t think we’ll have the final word on all this before
> 2.2.4. The way I see it we should keep working on improving it, but
> there are difficult choices to make, so it will probably take a bit of
> time.
Sounds good.
Thanks,
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-06-30 21:49 ` Mark H Weaver
@ 2018-07-01 10:12 ` Andy Wingo
2018-07-03 19:01 ` Mark H Weaver
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2018-07-01 10:12 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 28211
Hi!
First of all, I said on IRC but: ___nice___ debugging, Ludo! An
impressive show of persistence. Thanks Mark also for insightful
comments!
On Sat 30 Jun 2018 23:49, Mark H Weaver <mhw@netris.org> writes:
>>> I should say that I'm not confident that _either_ of these proposed
>>> solutions will adequately address all of the possible problems that
>>> could occur when GC is performed on VM threads stopped at arbitrary
>>> points in their execution.
>>
>> Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
>> that each stack is marked by the thread it belongs to, in terms of data
>> locality, and thus also in terms of being sure that vp->fp is up-to-date
>> when the marker reads it. It’s not something we can change now, though.
>
> I'm not sure it matters what thread the marking is done in, because when
> the actual collection happens, all threads are first stopped in their
> signal handlers, and presumably the appropriate memory barriers are
> performed so that all threads are synchronized before the full
> collection.
I think you are right here. Still, it would be nice from a locality
POV if threads could mark themselves. In some future I think it would
be nice if threads cooperatively reached safepoints, instead of using
the signal mechanism. In that case we could precisely mark the most
recent stack frame as well.
>> Anyway, I don’t think we’ll have the final word on all this before
>> 2.2.4. The way I see it we should keep working on improving it, but
>> there are difficult choices to make, so it will probably take a bit of
>> time.
>
> Sounds good.
Yeah! Really great that this is fixed, and apologies for introducing it
in the first place!!
A
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2
2017-08-23 22:20 bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Ludovic Courtès
2017-08-23 22:48 ` Ludovic Courtès
2018-04-24 16:03 ` Ludovic Courtès
@ 2018-07-02 10:28 ` Ludovic Courtès
2 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2018-07-02 10:28 UTC (permalink / raw)
To: 28211
Hi,
ludo@gnu.org (Ludovic Courtès) skribis:
> On current ‘core-updates’, the code in (guix build graft) triggers
> random Guile crashes (GC issue? thread-safety issue?) when running on
> Guile 2.2.2, as initially reported by Marius at
> <https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00013.html>:
>
> grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
> ERROR: In procedure put-bytevector: Wrong type argument in position 1 (expecting open output port): #<closed: file 8f1930>
> builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
>
> [...]
>
> ludo@ribbon ~/src/guix/+core-updates$ guix gc --clear-failures $(guix gc --list-failures)
> ludo@ribbon ~/src/guix/+core-updates$ guix build /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
> La jena derivo estos konstruata:
> /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
> @ build-started /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - x86_64-linux /var/log/guix/drvs/3c//rrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv.bz2
> grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
> ERROR: In procedure put-bytevector: Wrong type argument in position 1 (expecting open output port): #<closed: file 7517e0>
> builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
> @ build-failed /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - 1 builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
> guix build: error: build failed: build of `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed
> ludo@ribbon ~/src/guix/+core-updates$ guix gc --clear-failures $(guix gc --list-failures)
> ludo@ribbon ~/src/guix/+core-updates$ guix build /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
> La jena derivo estos konstruata:
> /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv
> @ build-started /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - x86_64-linux /var/log/guix/drvs/3c//rrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv.bz2
> grafting '/gnu/store/i71kkrch1asnwvm0vm71w9aaza0n2m9q-icecat-52.1.0-gnu1' -> '/gnu/store/7w92kgcdcmf7lsc9nvs6b2ca7mk9422s-icecat-52.1.0-gnu1'...
> ERROR: In procedure variable-ref: Not a variable: (194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255)
> builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
> @ build-failed /gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv - 1 builder for `/gnu/store/3crrls3ms9m3g860yvqib02rnm7akhf8-icecat-52.1.0-gnu1.drv' failed with exit code 1
Bad news: when using Guile 2.2.4 for grafting, I’m still getting similar
crashes, perhaps marginally less frequently.
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code
2018-07-01 10:12 ` Andy Wingo
@ 2018-07-03 19:01 ` Mark H Weaver
0 siblings, 0 replies; 23+ messages in thread
From: Mark H Weaver @ 2018-07-03 19:01 UTC (permalink / raw)
To: Andy Wingo; +Cc: 28211
Hi Andy,
Andy Wingo <wingo@igalia.com> writes:
> On Sat 30 Jun 2018 23:49, Mark H Weaver <mhw@netris.org> writes:
>
>>>> I should say that I'm not confident that _either_ of these proposed
>>>> solutions will adequately address all of the possible problems that
>>>> could occur when GC is performed on VM threads stopped at arbitrary
>>>> points in their execution.
>>>
>>> Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
>>> that each stack is marked by the thread it belongs to, in terms of data
>>> locality, and thus also in terms of being sure that vp->fp is up-to-date
>>> when the marker reads it. It’s not something we can change now, though.
>>
>> I'm not sure it matters what thread the marking is done in, because when
>> the actual collection happens, all threads are first stopped in their
>> signal handlers, and presumably the appropriate memory barriers are
>> performed so that all threads are synchronized before the full
>> collection.
>
> I think you are right here. Still, it would be nice from a locality
> POV if threads could mark themselves. In some future I think it would
> be nice if threads cooperatively reached safepoints, instead of using
> the signal mechanism. In that case we could precisely mark the most
> recent stack frame as well.
I agree that stopping threads at safepoints before collections would be
ideal.
>>> Anyway, I don’t think we’ll have the final word on all this before
>>> 2.2.4. The way I see it we should keep working on improving it, but
>>> there are difficult choices to make, so it will probably take a bit of
>>> time.
>>
>> Sounds good.
>
> Yeah! Really great that this is fixed, and apologies for introducing it
> in the first place!!
It's great that Ludovic found the problem (great debugging Ludovic!),
but FWIW, my assessment is that this bug is not fixed by commit
23af45e248e8e2bec99c712842bf24d6661abbe2, and therefore is not fixed in
Guile-2.2.4, contrary to the claims made in the commit log and the NEWS.
Unless I'm mistaken, that commit makes *no* difference to the
requirements on the compiler regarding the order of those writes.
Mark
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code, 2020 edition
2018-06-29 15:03 ` bug#28211: Stack marking issue in multi-threaded code Ludovic Courtès
2018-06-29 16:54 ` Mark H Weaver
@ 2020-03-12 21:59 ` Ludovic Courtès
2020-03-13 22:38 ` Ludovic Courtès
2020-03-17 21:16 ` Andy Wingo
1 sibling, 2 replies; 23+ messages in thread
From: Ludovic Courtès @ 2020-03-12 21:59 UTC (permalink / raw)
To: Andy Wingo; +Cc: 28211
Hi!
I think I’ve found another race condition involving stack marking, as a
followup to <https://issues.guix.gnu.org/issue/28211> (this time on
3.0.1+, but the code is almost the same.)
‘abort_to_prompt’ does this:
--8<---------------cut here---------------start------------->8---
fp = vp->stack_top - fp_offset;
sp = vp->stack_top - sp_offset;
/* Continuation gets nargs+1 values: the one more is for the cont. */
sp = sp - nargs - 1;
/* Shuffle abort arguments down to the prompt continuation. We have
to be jumping to an older part of the stack. */
if (sp < vp->sp)
abort ();
sp[nargs].as_scm = cont;
while (nargs--)
sp[nargs] = vp->sp[nargs];
/* Restore VM regs */
vp->fp = fp;
vp->sp = sp;
vp->ip = vra;
--8<---------------cut here---------------end--------------->8---
What if ‘scm_i_vm_mark_stack’ walks the stack right before the ‘vp->fp’
assignment? It can determine that one of the just-assigned ‘sp[nargs]’
is a dead slot, and thus set it to SCM_UNSPECIFIED. Later, when we set
‘vp->fp’, that stack slot that we just initialized has been overwritten
by ‘scm_i_vm_mark_stack’. Down the road, we get something like:
Wrong type to apply: #<unspecified>
I believe this is what I’m seeing here (0x7ff7f838dda0 is being set to
SCM_UNSPECIFIED while thread 2 is in ‘abort_to_prompt’):
--8<---------------cut here---------------start------------->8---
(rr) thread 5
[Switching to thread 5 (Thread 24572.24575)]
#0 scm_i_vm_mark_stack (vp=0x7ff7fd820b48, mark_stack_ptr=0x7ff7fc0ebf90,
mark_stack_limit=0x7ff7fc0fbec0) at vm.c:743
743 break;
(rr) list
738 break;
739 case SLOT_DESC_DEAD:
740 /* This value may become dead as a result of GC,
741 so we can't just leave it on the stack. */
742 sp->as_scm = SCM_UNSPECIFIED;
743 break;
744 }
745 }
746 sp = SCM_FRAME_PREVIOUS_SP (fp);
747 /* Inner frames may have a dead slots map for precise marking.
(rr) p sp->as_scm
$59 = #<unspecified>
(rr) p sp
$60 = (union scm_vm_stack_element *) 0x7ff7f838dda0
(rr) thread 2
[Switching to thread 2 (Thread 24572.24577)]
#0 0x00007ff7fdb7bb36 in __GI___sigsuspend (
set=set@entry=0x7ff7fe132720 <suspend_handler_mask>)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
26 ../sysdeps/unix/sysv/linux/sigsuspend.c: Dosiero aŭ dosierujo ne ekzistas.
(rr) frame 4
#4 0x00007ff7fe228f14 in abort_to_prompt (thread=0x7ff7fd820b40,
saved_mra=<optimized out>) at vm.c:1465
1465 sp[nargs] = vp->sp[nargs];
(rr) p sp
$61 = (union scm_vm_stack_element *) 0x7ff7f838dd90
(rr) p fp
$62 = (union scm_vm_stack_element *) 0x7ff7f838ddb0
(rr) p &sp[2]
$63 = (union scm_vm_stack_element *) 0x7ff7f838dda0
(rr) p vp->sp
$64 = (union scm_vm_stack_element *) 0x7ff7f838dcf0
(rr) p vp->fp
$65 = (union scm_vm_stack_element *) 0x7ff7f838dd08
(rr) p vp->stack_bottom
$66 = (union scm_vm_stack_element *) 0x7ff7f838a000
(rr) p vp->stack_top
$67 = (union scm_vm_stack_element *) 0x7ff7f838e000
--8<---------------cut here---------------end--------------->8---
Comments about this analysis?
How do we fix it? It’s a bit troubling that this is all lock-free. A
fix I can think of is to just re-do the sp[nargs] assignments after the
vp->sp etc. assignments.
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code, 2020 edition
2020-03-12 21:59 ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès
@ 2020-03-13 22:38 ` Ludovic Courtès
2020-03-17 21:16 ` Andy Wingo
1 sibling, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2020-03-13 22:38 UTC (permalink / raw)
To: Andy Wingo; +Cc: 28211
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
Hi,
Ludovic Courtès <ludo@gnu.org> skribis:
> What if ‘scm_i_vm_mark_stack’ walks the stack right before the ‘vp->fp’
> assignment? It can determine that one of the just-assigned ‘sp[nargs]’
> is a dead slot, and thus set it to SCM_UNSPECIFIED. Later, when we set
> ‘vp->fp’, that stack slot that we just initialized has been overwritten
> by ‘scm_i_vm_mark_stack’. Down the road, we get something like:
>
> Wrong type to apply: #<unspecified>
I believe the patch below solves this problem. Also attached is a small
program that reproduces the bug (without the patch) after a couple of
minutes.
Thoughts?
The full grafting test case exposes another VM stack-corruption-looking
crash that I’m still investigating.
Ludo’.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2720 bytes --]
diff --git a/libguile/vm.c b/libguile/vm.c
index b20c6eb5f..5cc934e99 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -1351,7 +1351,8 @@ scm_i_vm_emergency_abort (SCM *tag_and_argv, size_t n)
scm_t_bits *prompt;
scm_t_dynstack_prompt_flags flags;
ptrdiff_t fp_offset, sp_offset;
- union scm_vm_stack_element *fp, *sp;
+ union scm_vm_stack_element *fp;
+ volatile union scm_vm_stack_element *sp;
SCM *argv;
uint32_t *vra;
uint8_t *mra;
@@ -1392,16 +1393,19 @@ scm_i_vm_emergency_abort (SCM *tag_and_argv, size_t n)
to be jumping to an older part of the stack. */
if (sp < vp->sp)
abort ();
- sp[nargs].as_scm = cont;
-
- while (nargs--)
- sp[nargs].as_scm = *argv++;
/* Restore VM regs */
vp->fp = fp;
- vp->sp = sp;
+ vp->sp = (union scm_vm_stack_element *) sp;
vp->ip = vra;
+ /* Restore the arguments on SP. This must be done after 'vp->fp' has
+ been set so that a concurrent 'scm_i_vm_mark_stack' does not
+ overwrite it (see <https://bugs.gnu.org/28211>). */
+ sp[nargs].as_scm = cont;
+ while (nargs--)
+ sp[nargs].as_scm = *argv++;
+
/* Jump! */
vp->mra_after_abort = mra;
longjmp (*registers, 1);
@@ -1417,7 +1421,8 @@ abort_to_prompt (scm_thread *thread, uint8_t *saved_mra)
scm_t_bits *prompt;
scm_t_dynstack_prompt_flags flags;
ptrdiff_t fp_offset, sp_offset;
- union scm_vm_stack_element *fp, *sp;
+ union scm_vm_stack_element *fp, *orig_sp;
+ volatile union scm_vm_stack_element *sp;
uint32_t *vra;
uint8_t *mra;
jmp_buf *registers;
@@ -1452,6 +1457,7 @@ abort_to_prompt (scm_thread *thread, uint8_t *saved_mra)
/* Recompute FP, as scm_dynstack_unwind may have expanded the stack. */
fp = vp->stack_top - fp_offset;
sp = vp->stack_top - sp_offset;
+ orig_sp = vp->sp;
/* Continuation gets nargs+1 values: the one more is for the cont. */
sp = sp - nargs - 1;
@@ -1460,15 +1466,19 @@ abort_to_prompt (scm_thread *thread, uint8_t *saved_mra)
to be jumping to an older part of the stack. */
if (sp < vp->sp)
abort ();
- sp[nargs].as_scm = cont;
- while (nargs--)
- sp[nargs] = vp->sp[nargs];
/* Restore VM regs */
vp->fp = fp;
- vp->sp = sp;
+ vp->sp = (union scm_vm_stack_element *) sp;
vp->ip = vra;
+ /* Restore the arguments on SP. This must be done after 'vp->fp' has
+ been set so that a concurrent 'scm_i_vm_mark_stack' does not
+ overwrite it (see <https://bugs.gnu.org/28211>). */
+ sp[nargs].as_scm = cont;
+ while (nargs--)
+ sp[nargs] = orig_sp[nargs];
+
/* If there are intervening C frames, then jump over them, making a
nonlocal exit. Otherwise fall through and let the VM pick up where
it left off. */
[-- Attachment #3: the reproducer --]
[-- Type: text/plain, Size: 434 bytes --]
;; https://issues.guix.gnu.org/issue/28211
(use-modules (ice-9 threads))
(define (thunk)
(catch 'foo
(lambda ()
(throw 'foo (iota 10)))
(lambda (key lst)
(unless (equal? lst (iota 10))
(primitive-_exit 42)))))
(n-par-for-each (* 2 (current-processor-count))
(lambda _
(let loop ()
(thunk)
(loop)))
(iota 1000))
^ permalink raw reply related [flat|nested] 23+ messages in thread
* bug#28211: Stack marking issue in multi-threaded code, 2020 edition
2020-03-12 21:59 ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès
2020-03-13 22:38 ` Ludovic Courtès
@ 2020-03-17 21:16 ` Andy Wingo
1 sibling, 0 replies; 23+ messages in thread
From: Andy Wingo @ 2020-03-17 21:16 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 28211
On Thu 12 Mar 2020 22:59, Ludovic Courtès <ludo@gnu.org> writes:
> I think I’ve found another race condition involving stack marking, as a
> followup to <https://issues.guix.gnu.org/issue/28211> (this time on
> 3.0.1+, but the code is almost the same.)
>
> ‘abort_to_prompt’ does this:
>
> fp = vp->stack_top - fp_offset;
> sp = vp->stack_top - sp_offset;
>
> /* Continuation gets nargs+1 values: the one more is for the cont. */
> sp = sp - nargs - 1;
>
> /* Shuffle abort arguments down to the prompt continuation. We have
> to be jumping to an older part of the stack. */
> if (sp < vp->sp)
> abort ();
> sp[nargs].as_scm = cont;
> while (nargs--)
> sp[nargs] = vp->sp[nargs];
>
> /* Restore VM regs */
> vp->fp = fp;
> vp->sp = sp;
> vp->ip = vra;
>
>
> What if ‘scm_i_vm_mark_stack’ walks the stack right before the ‘vp->fp’
> assignment? It can determine that one of the just-assigned ‘sp[nargs]’
> is a dead slot, and thus set it to SCM_UNSPECIFIED.
I think you're right here.
Given that the most-recently-pushed frame is marked conservatively, I
think it would be sufficient to reset vp->fp before shuffling stack
args; that would make it so that the frame includes the values to
shuffle, their target locations, and probably some other crap in
between. Given that marking the crap is harmless, I think that would be
enough. WDYT?
In a more perfect world, initiating GC should tell threads to reach a
safepoint and mark their own stacks -- preserves thread locality and
prevents this class of bug. But given that libgc uses signals to stop
threads, we have to be less precise.
Cheers,
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-03-17 21:17 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-23 22:20 bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Ludovic Courtès
2017-08-23 22:48 ` Ludovic Courtès
2018-04-24 16:03 ` Ludovic Courtès
2018-05-08 21:55 ` Ludovic Courtès
2018-05-09 0:32 ` Mark H Weaver
2018-05-09 7:17 ` Ludovic Courtès
2018-05-09 9:11 ` Andy Wingo
2018-05-10 6:50 ` Mark H Weaver
2018-05-10 7:53 ` Andy Wingo
2018-06-29 15:03 ` bug#28211: Stack marking issue in multi-threaded code Ludovic Courtès
2018-06-29 16:54 ` Mark H Weaver
2018-06-29 21:18 ` Ludovic Courtès
2018-06-29 23:18 ` Mark H Weaver
2018-06-30 20:53 ` Ludovic Courtès
2018-06-30 21:49 ` Mark H Weaver
2018-07-01 10:12 ` Andy Wingo
2018-07-03 19:01 ` Mark H Weaver
2020-03-12 21:59 ` bug#28211: Stack marking issue in multi-threaded code, 2020 edition Ludovic Courtès
2020-03-13 22:38 ` Ludovic Courtès
2020-03-17 21:16 ` Andy Wingo
2018-05-10 15:48 ` bug#28211: Grafting code triggers GC/thread-safety issue on Guile 2.2.2 Mark H Weaver
2018-05-10 16:01 ` Mark H Weaver
2018-07-02 10:28 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).