--- Begin Message ---
|
Subject: |
Assert triggered (hashtab.c:137) - Guile-2.0.9 |
|
Date: |
Tue, 4 Feb 2014 10:43:48 +0200 (SAST) |
Hi,
We have a system running and was fine for about a month, all the code paths
should have been exercised, and the system then threw an assert when it was not
processing any requests.
The system runs in a loop and reads values from a database, and also forces a
garbage collect every so often.
The assert error thrown:
Assertion failed: removed <= len, file hashtab.c, line 137
The following libraries are used:
gcc 4.7.2
bdw-gc 7.2
libtool 2.2.10
gmp 5.0.2
libiconv 1.14
libunistring 0.9.3
libffi 3.0.10
readline 6.1
guile 2.0.9
guile-lib 0.2.2
guile-dbi 2.1.5
mysql 5.1.53
guile-dbd-mysql 2.1.4
guile-xmlrpc 0.2.1
The configure flags for guile-2.0.9:
( cd guile-2.0.9 ; CONFIG_SHELL=/bin/bash
BDW_GC_CFLAGS="-I/opt/cs/components/3rd/bdw-gc/7.2.7e16628s16377h0398//include/"
BDW_GC_LIBS="-L/opt/cs/components/3rd/bdw-gc/7.2.7e16628s16377h0398//lib -lgc"
LIBFFI_CFLAGS="-I/opt/cs/components/3rd/libffi/3.0.10f3e16407s16377h0398//include/"
LIBFFI_LIBS="-L/opt/cs/components/3rd/libffi/3.0.10f3e16407s16377h0398//lib
-lffi"
LD_LIBRARY_PATH=/opt/cs/components/3rd/gcc/4.7.2f3e16377s0h0000/lib/amd64/:/opt/cs/components/3rd/gcc/4.7.2f3e16377s0h0000/lib/:/opt/cs/components/3rd/bdw-gc/7.2.7e16628s16377h0398/lib/amd64/:/opt/cs/components/3rd/bdw-gc/7.2.7e16628s16377h0398/lib/:/opt/cs/components/3rd/libtool/2.2.10f3e16399s16377h0398/lib/amd64/:/opt/cs/components/3rd/libtool/2.2.10f3e16399s16377h0398/lib/:/opt/cs/components/3rd/gmp/5.0.2f3e16407s16377h0398/lib/amd64/:/opt/cs/components/3rd/gmp/5.0.2f3e16407s16377h0398/lib/:/opt/cs/components/3rd/libiconv/1.14.0f3e16407s16377h0398/lib/amd64/:/opt/cs/components/3rd/libiconv/1.14.0f3e16407s16377h0398/lib/:/opt/cs/components/3rd/libunistring/0.9.3f3e16407s32784h27b7/lib/amd64/:/opt/cs/components/3rd/libunistring/0.9.3f3e16407s32784h27b7/lib/:/opt/cs/components/3rd/libffi/3.0.10f3e16407s16377h0398/lib/amd64/:/opt/cs/components/3rd/libffi/3.0.10f3e16407s16377h0398/lib/:/opt/cs/components/3rd/readline/6.1.0f3e16318s16377h0398/lib/amd64/:/opt/cs/components/3rd/readline/6.1.0f3e16318s16377h0398/lib/:/opt/cs/components/3rd/make/3.81.0f3e16404s0h0000//lib/amd64:/opt/cs/components/3rd/make/3.81.0f3e16404s0h0000//lib:
AR="gar" RANLIB="granlib" CC="gcc-4.7.2f3e16377s0h0000"
CXX="g++-4.7.2f3e16377s0h0000" LD="/usr/ccs/bin/ld"
INSTALL="/opt/csw/bin/ginstall -g cs" INSTALL_DATA="/opt/csw/bin/ginstall
-g cs -m 0660" INSTALL_PROGRAM="/opt/csw/bin/ginstall -g cs -m 0770"
INSTALL_DIRECTORY="cs-dirs-install -g cs -m 2770"
INSTALL_DIR="cs-dirs-install -g cs -m 2770" CXXFLAGS="-m64" CFLAGS="-m64
-O2" LDFLAGS="-m64"
/opt/cs/components/3rd/make/3.81.0f3e16404s0h0000/bin/make MAKE_SHELL=bash
SHELL=bash V=1)
The configure flags and arguments for bdw-gc-7.2:
AR="gar" RANLIB="granlib" CC="gcc-4.7.2f3e16377s0h0000"
CXX="g++-4.7.2f3e16377s0h0000" LD="/usr/ccs/bin/ld"
INSTALL="/opt/csw/bin/ginstall -g cs" INSTALL_DATA="/opt/csw/bin/ginstall
-g cs -m 0660" INSTALL_PROGRAM="/opt/csw/bin/ginstall -g cs -m 0770"
INSTALL_DIRECTORY="cs-dirs-install -g cs -m 2770"
INSTALL_DIR="cs-dirs-install -g cs -m 2770" CXXFLAGS="-m64" CFLAGS="-m64"
LDFLAGS="-m64" \
CONFIG_SHELL=/bin/bash /bin/bash configure
--prefix=/opt/cs/components/3rd/bdw-gc/7.2.7e16628s16377h0398
--enable-threads=posix --enable-thread-local-alloc --enable-parallel-mark
--disable-dependency-tracking --enable-large-config --enable-handle-fork
--enable-gc-assertions
If you have any suggestions I would be glad to hear.
Regards
/Cole
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#16641: Assert triggered (hashtab.c:137) - Guile-2.0.9 |
|
Date: |
Tue, 21 Jun 2016 14:58:17 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
On Wed 05 Feb 2014 16:56, Mark H Weaver <address@hidden> writes:
> Also: this is on Solaris 10u10. Cole mentioned that on IRC.
On the one hand I don't understand how this can happen. On the other, I
unfortunately don't have faith in the buckets-and-chains weak table
implementation in 2.0; it usually works but it's gnarly and is a
threading nightmare, and accesses disappearing links outside the alloc
lock. See for example:
http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/4789
In 2.2 the weak table is rewritten to not require the "vacuum" phase and
to be threadsafe. That was my best effort at fixing this bug but I
couldn't do it with some of the constraints in 2.0. For that reason I
am closing this one but feel free to re-open it if you find available
hackpower to work towards a solution for 2.0.
Andy
--- End Message ---