bug#19180: vacuum_weak_hash_table error

[Anand Mohanadoss]

Dear Ludovic,

I apologize for the late response.  We rebuilt guile from scratch with the latest GC (7.2f) and the patch you provided.  We got a 73GB output file in reproducing the problem with the extra logging!  I am attaching the last 100,000 lines of output as a file.  Appended is the stack trace.  Can you kindly take a look when you get a chance?

It appears that len becomes 0 after successive removals and then we hit the assertion failure when len is 0 and removed is 1.

Thanks,

Anand

#0  0x00e93430 in __kernel_vsyscall ()
#1  0x001e4b01 in raise () from /lib/libc.so.6
#2  0x001e63da in abort () from /lib/libc.so.6
#3  0x001ddddb in __assert_fail_base () from /lib/libc.so.6
#4  0x001dde96 in __assert_fail () from /lib/libc.so.6
#5  0x080e9ad0 in vacuum_weak_hash_table (table=0xa86c840) at hashtab.c:138
#6  0x080e97f7 in weak_gc_callback (hook_data=0x0, fn_data=0x6, data="" at hashtab.c:440
#7  weak_gc_hook (hook_data=0x0, fn_data=0x6, data="" at hashtab.c:449
#8  0x080eac7d in scm_c_hook_run (hook=0x8961ba0, data="" at hooks.c:103
#9  0x080dff76 in run_before_gc_c_hook () at gc.c:240
#10 0x08188ed9 in GC_notify_full_gc (stop_func=0x8188090 <GC_never_stop_func>) at alloc.c:335
#11 GC_try_to_collect_inner (stop_func=0x8188090 <GC_never_stop_func>) at alloc.c:430
#12 0x081894db in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0, retry=0) at alloc.c:1253
#13 0x0818963c in GC_allocobj (gran=2, kind=0) at alloc.c:1340
#14 0x0818c066 in GC_generic_malloc_inner (lb=16, k=0) at malloc.c:121
#15 0x0818ccb6 in GC_generic_malloc_many (lb=16, k=0, result=0xb4c372c) at mallocx.c:423
#16 0x08194ee8 in GC_malloc_atomic (bytes=16) at thread_local_alloc.c:195
#17 0x080df522 in do_gc_malloc_atomic (size=0, what=0x6 <Address 0x6 out of bounds>) at gc-malloc.c:106
#18 0x080f612b in make_bignum () at numbers.c:253
#19 scm_i_mkbig () at numbers.c:267
#20 0x080f8ae5 in scm_difference (x=0xbc8f260, y=0xd3412b0) at numbers.c:7861
#21 0x08143434 in vm_regular_engine (vm=0xc001b50, program=0x0, argv=0xbc8f260, nargs=0) at vm-i-scheme.c:414
#22 0x0813c5b7 in scm_c_vm_run (vm=0xc001b50, program=0xb44f400, argv=0x0, nargs=0) at vm.c:768
#23 0x080d8f7a in scm_call_0 (proc=0xb44f400) at eval.c:480
#24 0x08137c9b in really_launch (d=0xfface2a0) at threads.c:1005
#25 0x08163dc2 in c_body (d=0xf61d620c) at continuations.c:517
#26 0x08143d7d in vm_regular_engine (vm=0xc001b50, program=0x0, argv=0x2, nargs=4) at vm-i-system.c:858
#27 0x0813c5b7 in scm_c_vm_run (vm=0xc001b50, program=0xaa0ddc8, argv=0xf61d6168, nargs=4) at vm.c:768
#28 0x080d8e91 in scm_call_4 (proc=0xaa0ddc8, arg1=0x404, arg2=0xc005ef0, arg3=0xc005ee0, arg4=0xc005ed0) at eval.c:507
#29 0x08138c5e in scm_catch_with_pre_unwind_handler (key=0x404, thunk=0xc005ef0, handler=0xc005ee0, pre_unwind_handler=0xc005ed0) at throw.c:73
#30 0x08164067 in scm_i_with_continuation_barrier (body=0x8163db0 <c_body>, body_data=0xf61d620c, handler=0x8163fb0 <c_handler>, handler_data=0xf61d620c,
    pre_unwind_handler=0x8163e00 <pre_unwind_handler>, pre_unwind_handler_data=0xa9daff8) at continuations.c:455
#31 0x08164102 in scm_c_with_continuation_barrier (func=0x8137c10 <really_launch>, data="" at continuations.c:551
#32 0x08137a52 in with_guile_and_parent (base=0xf61d626c, data="" at threads.c:906
#33 0x081900ff in GC_call_with_stack_base (fn=0x8137a10 <with_guile_and_parent>, arg=0xf61d628c) at misc.c:1573
#34 0x081375c2 in scm_i_with_guile_and_parent (func=<value optimized out>, data="" parent=0x2740) at threads.c:949
#35 0x08137625 in launch_thread (d=0xfface2a0) at threads.c:1017
#36 0x08199cdb in GC_inner_start_routine (sb=0xf61d633c, arg=0xbc87fc0) at pthread_start.c:56
#37 0x081900ff in GC_call_with_stack_base (fn=0x8199c80 <GC_inner_start_routine>, arg=0xbc87fc0) at misc.c:1573
#38 0x08195319 in GC_start_routine (arg=0xbc87fc0) at pthread_support.c:1549
#39 0x00146a49 in start_thread () from /lib/libpthread.so.0
#40 0x00298e1e in clone () from /lib/libc.so.6

On Wed, Dec 3, 2014 at 1:17 AM, Ludovic Courtès <address@hidden> wrote:

Anand Mohanadoss <address@hidden> skribis:

> #4  0x003b8e96 in __assert_fail () from /lib/libc.so.6
> #5  0x080e93d7 in vacuum_weak_hash_table (table=0x97f8b10) at hashtab.c:137
> #6  0x080e9857 in weak_gc_callback (hook_data=0x0, fn_data=0x6, data=""> > at hashtab.c:437
> #7  weak_gc_hook (hook_data=0x0, fn_data=0x6, data="" at hashtab.c:446
> #8  0x080eaa2d in scm_c_hook_run (hook=0x895acc0, data="" at hooks.c:103
> #9  0x080dfda6 in run_before_gc_c_hook () at gc.c:240
> #10 0x08187719 in GC_notify_full_gc (stop_func=0x81868e0
> <GC_never_stop_func>) at alloc.c:334
> #11 GC_try_to_collect_inner (stop_func=0x81868e0 <GC_never_stop_func>) at
> alloc.c:429
> #12 0x08187d1b in GC_collect_or_expand (needed_blocks=4, ignore_off_page=0,
> retry=0) at alloc.c:1242
> #13 0x0818a64f in GC_alloc_large (lb=14080, k=1, flags=0) at malloc.c:63
> #14 0x0818a9c2 in GC_generic_malloc (lb=14076, k=1) at malloc.c:175
> #15 0x0818ace7 in GC_core_malloc (lb=14076) at malloc.c:263
> #16 0x080df572 in do_gc_malloc (size=0, what=0x6 <Address 0x6 out of
> bounds>) at gc-malloc.c:100
> #17 0x0813a565 in scm_c_make_vector (k=3517, fill=0x304) at vectors.c:408
> #18 0x080e9471 in scm_i_rehash (table=0x97f8b10, hash_fn=0x816c1d0
> <scm_ihashq>, closure=0x0, func_name=0x854f8bd
> "scm_hash_fn_create_handle_x") at hashtab.c:344

Looking at this stack trace, it seems ‘table’ is being concurrently
modified: a GC occurs while it is being rehashed.

Could you apply with attached patch (with “patch -p1 < the-patch” run
from the top of the source tree), and report the lines that are printed
before the assertion failure?

Also, please report the corresponding backtrace, as you did above (just
to make sure this is the same scenario.)

Thanks in advance,
Ludo’.

guile.patch.txt
Description: Text document