Re: Build Error in master
On Thu 26 Jan 2012 15:26, Noah Lavine writes: > I just checked out the latest master. I attempted to build it, but got > stuck at this point: Is it http://lists.gnu.org/archive/html/bug-guile/2011-12/msg00058.html ? Andy -- http://wingolog.org/
Re: Build Error in master
I don't think so, because I don't get
Throw to key misc-error with args ("module-transformer" "no module, and
`macroexpand' unbound" () #f).
I'm going to try a git bisect and see where this appears.
Noah
On Thu, Jan 26, 2012 at 5:06 PM, Andy Wingo wrote:
> On Thu 26 Jan 2012 15:26, Noah Lavine writes:
>
>> I just checked out the latest master. I attempted to build it, but got
>> stuck at this point:
>
> Is it http://lists.gnu.org/archive/html/bug-guile/2011-12/msg00058.html
> ?
>
> Andy
> --
> http://wingolog.org/
Re: Build Error in master
Il giorno 26 gennaio 2012 23:06, Andy Wingo ha scritto: > On Thu 26 Jan 2012 15:26, Noah Lavine writes: > > > I just checked out the latest master. I attempted to build it, but got > > stuck at this point: > > Is it http://lists.gnu.org/archive/html/bug-guile/2011-12/msg00058.html > ? > yyes, in my case, this is what happens with the version checked out from git. The tarballed 3.0.2 works fine Hope this helps
Re: Build Error in master
I've done some debugging. Here is what I know so far: The error happens in scm_bootstrap_vm, which is called before we enter Scheme, so the error is only in the C code. It happens in scm_i_str2symbol, when scm_bootstrap_vm wants to make some symbol. Here's how symbols work: there is a variable called 'symbols', in symbols.c, which is a weak set holding all of our symbols. This is presumably how we intern them. When scm_i_str2symbol wants to make a new symbol, it first checks if the symbol already exists, and if it does not, calls scm_c_weak_set_add_x with the symbols set and the new symbol. scm_i_str2symbol passes the 'symbols' object to scm_c_weak_set_add_x. scm_c_weak_set_add_x then unpacks it (it is an SCM) to get an scm_t_weak_set. That weak set was stored in 'symbols' by scm_symbols_prehistory. However, in the run that fails, scm_c_weak_set_add_x unpacks a *different* scm_t_weak_set value than scm_symbols_prehistory stored there. This value points to memory that is not allocated, which is where we get the segmentation fault. More specifically, In scm_symbols_prehistory, the "symbols" set is at 0x1006cff50, and the SCM 'symbols' is 0x10101cff0 In the failing call, the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, which has not been allocated. So the question is, what might change this value wrongly? Does anyone know? Or alternatively, what's a good way for me to debug this? Thanks, Noah On Sun, Jan 29, 2012 at 3:21 PM, Catonano wrote: > > > Il giorno 26 gennaio 2012 23:06, Andy Wingo ha scritto: > >> On Thu 26 Jan 2012 15:26, Noah Lavine writes: >> >> > I just checked out the latest master. I attempted to build it, but got >> > stuck at this point: >> >> Is it http://lists.gnu.org/archive/html/bug-guile/2011-12/msg00058.html >> ? > > > yyes, in my case, this is what happens with the version checked out from > git. > > The tarballed 3.0.2 works fine > > Hope this helps
Re: Build Error in master
On Wed 01 Feb 2012 03:12, Noah Lavine writes: > In the failing call, > the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, > which has not been allocated. 0x304 is one of the iflags, SCM_EOL I think. So, I know it might not have anything to do with it, but can you verify that your guile includes patch 0aed71aa51e89e714de2392c2a5f44694dca77ea ? I just committed that last night, and although it does not seem to be related, who knows. Andy -- http://wingolog.org/
Re: Build Error in master
Got it! And unfortunately, it's a GC error. Here's what happens: symbols is an SCM object defined in symbols.c. It points to an scm_cell_t which has two elements: a type tag, and a pointer to an scm_weak_set_t. That scm_cell_t is at 0x10101cff0. However, that scm_cell_t is garbage collected in the scm_cons at symbols.c:250. The reason it gets filled with SCM_EOL is that the cons is scm_cons (SCM_BOOL_F, SCM_EOL). So I expect that the scm_cell_t is garbage collected and then immediately reclaimed to be the pair, which would result in its second cell being filled with SCM_EOL, which would explain why we later extract SCM_EOL from it. As a test, I changed the variable 'symbols' in symbols.c to be non-static. That didn't fix it, but then again, I don't really know how GC works yet. I can read the libgc documentation and try to figure this out, but can anyone point me to what I should be looking for? Thanks, Noah On Wed, Feb 1, 2012 at 4:01 AM, Andy Wingo wrote: > On Wed 01 Feb 2012 03:12, Noah Lavine writes: > >> In the failing call, >> the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, >> which has not been allocated. > > 0x304 is one of the iflags, SCM_EOL I think. > > So, I know it might not have anything to do with it, but can you verify > that your guile includes patch 0aed71aa51e89e714de2392c2a5f44694dca77ea > ? I just committed that last night, and although it does not seem to be > related, who knows. > > Andy > -- > http://wingolog.org/
Re: Build Error in master
Hello, I inserted a GC_is_visible check in my code and learned that 'symbols' is visible, but the things it points to were getting garbage collected anyway. It seemed like a GC bug, so I'm trying to build Guile with the latest version of GC and hoping that fixes it. I just wanted to warn everyone that the GC_get_free_space_divisor function will break with libgc 7.2alpha6, because libgc includes the same function with the same name. I'm not sure what to do about that - probably try to automatically discover it in configure and put more #ifdefs around our definition (gc.c:212). Noah On Thu, Feb 2, 2012 at 9:59 PM, Noah Lavine wrote: > Got it! And unfortunately, it's a GC error. Here's what happens: > > symbols is an SCM object defined in symbols.c. It points to an > scm_cell_t which has two elements: a type tag, and a pointer to an > scm_weak_set_t. That scm_cell_t is at 0x10101cff0. > > However, that scm_cell_t is garbage collected in the scm_cons at > symbols.c:250. The reason it gets filled with SCM_EOL is that the cons > is scm_cons (SCM_BOOL_F, SCM_EOL). So I expect that the scm_cell_t is > garbage collected and then immediately reclaimed to be the pair, which > would result in its second cell being filled with SCM_EOL, which would > explain why we later extract SCM_EOL from it. > > As a test, I changed the variable 'symbols' in symbols.c to be > non-static. That didn't fix it, but then again, I don't really know > how GC works yet. > > I can read the libgc documentation and try to figure this out, but can > anyone point me to what I should be looking for? > > Thanks, > Noah > > On Wed, Feb 1, 2012 at 4:01 AM, Andy Wingo wrote: >> On Wed 01 Feb 2012 03:12, Noah Lavine writes: >> >>> In the failing call, >>> the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, >>> which has not been allocated. >> >> 0x304 is one of the iflags, SCM_EOL I think. >> >> So, I know it might not have anything to do with it, but can you verify >> that your guile includes patch 0aed71aa51e89e714de2392c2a5f44694dca77ea >> ? I just committed that last night, and although it does not seem to be >> related, who knows. >> >> Andy >> -- >> http://wingolog.org/
Re: Build Error in master
Oh, and the same will happen with GC_get_suspend_signal, which we define at scmsigs.c:155. Other than that, though, the new gc resolves the problem I had. I am willing to chalk this up to a GC bug and not worry about it more. Noah On Tue, Feb 7, 2012 at 9:07 AM, Noah Lavine wrote: > Hello, > > I inserted a GC_is_visible check in my code and learned that 'symbols' > is visible, but the things it points to were getting garbage collected > anyway. It seemed like a GC bug, so I'm trying to build Guile with the > latest version of GC and hoping that fixes it. > > I just wanted to warn everyone that the GC_get_free_space_divisor > function will break with libgc 7.2alpha6, because libgc includes the > same function with the same name. I'm not sure what to do about that - > probably try to automatically discover it in configure and put more > #ifdefs around our definition (gc.c:212). > > Noah > > On Thu, Feb 2, 2012 at 9:59 PM, Noah Lavine wrote: >> Got it! And unfortunately, it's a GC error. Here's what happens: >> >> symbols is an SCM object defined in symbols.c. It points to an >> scm_cell_t which has two elements: a type tag, and a pointer to an >> scm_weak_set_t. That scm_cell_t is at 0x10101cff0. >> >> However, that scm_cell_t is garbage collected in the scm_cons at >> symbols.c:250. The reason it gets filled with SCM_EOL is that the cons >> is scm_cons (SCM_BOOL_F, SCM_EOL). So I expect that the scm_cell_t is >> garbage collected and then immediately reclaimed to be the pair, which >> would result in its second cell being filled with SCM_EOL, which would >> explain why we later extract SCM_EOL from it. >> >> As a test, I changed the variable 'symbols' in symbols.c to be >> non-static. That didn't fix it, but then again, I don't really know >> how GC works yet. >> >> I can read the libgc documentation and try to figure this out, but can >> anyone point me to what I should be looking for? >> >> Thanks, >> Noah >> >> On Wed, Feb 1, 2012 at 4:01 AM, Andy Wingo wrote: >>> On Wed 01 Feb 2012 03:12, Noah Lavine writes: >>> In the failing call, the SCM 'symbols' is 0x10101cff0, but the failing set is at 0x304, which has not been allocated. >>> >>> 0x304 is one of the iflags, SCM_EOL I think. >>> >>> So, I know it might not have anything to do with it, but can you verify >>> that your guile includes patch 0aed71aa51e89e714de2392c2a5f44694dca77ea >>> ? I just committed that last night, and although it does not seem to be >>> related, who knows. >>> >>> Andy >>> -- >>> http://wingolog.org/
Re: Build Error in Master
Hi Noah, Noah Lavine writes: > When building the latest git master, I get this error: > > GUILEC language/tree-il/compile-glil.go > Assertion failed: (table->n_items < size), function rob_from_rich, > file weak-table.c, line 252. > > Has weak-table.c changed recently? This is just a guess, but the recent elisp branch merge renumbered many of the VM instructions. After I recompiled the C files, Guile failed ungracefully with mysterious errors. Deleting all of the .go files and recompiling them fixed the problem for me. I found this a bit surprising, because the elisp merge _did_ bump the SCM_OBJCODE_MINOR_VERSION in _scm.h from 0 to 1. I would have expected that to force recompilations of the older .go files, but apparently it doesn't. Regards, Mark
Re: Build Error in Master
Hi Noah!
Noah Lavine skribis:
> When building the latest git master, I get this error:
>
> GUILEC language/tree-il/compile-glil.go
> Assertion failed: (table->n_items < size), function rob_from_rich,
> file weak-table.c, line 252.
I’m seeing that too sometimes when running ./check-guile, with this
backtrace (for all threads):
--8<---cut here---start->8---
Core was generated by `/data/src/guile-2.1/libguile/.libs/guile --debug
--no-auto-compile -e main -s /'.
Program terminated with signal 6, Aborted.
#0 0x7fe5a0a7e85e in raise ()
from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
Thread 6 (Thread 8050):
#0 0x7fe5a20155ac in pthread_cond_wait@@GLIBC_2.3.2 ()
from
/nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
No symbol table info available.
#1 0x7fe5a25601bb in scm_pthread_cond_wait (cond=0x28abe88,
mutex=0x23d4370)
at threads.c:1986
res = -512
t = 0x28abe00
#2 0x7fe5a25606d8 in block_self (queue=0x1c4c610, sleep_object=,
mutex=0x23d4370, waittime=0x0) at threads.c:451
t = 0x28abe00
q_handle = 0x1e173c0
err =
#3 0x7fe5a2560d43 in fat_mutex_unlock (mutex=0x1c4c690, cond=0x1c4c620,
waittime=0x0,
relock=1) at threads.c:1627
brk = 0
owner = 0x1cc5ed0
m = 0x23d4370
c = 0x1bb20c0
t = 0x28abe00
err =
ret =
#4 0x7fe5a2560ef9 in scm_timed_wait_condition_variable (cv=0x1c4c620,
mx=0x1c4c690, t=0x904)
at threads.c:1811
waittime = {tv_sec = 47438496, tv_nsec = 140624247786400}
waitptr =
#5 0x7fe5a256c14f in vm_debug_engine (vm=0x1cc5e80, program=0x21801c0,
argv=0x0, nargs=0)
at vm-i-system.c:911
subr = 0x7fe5a2560e90
vp = 0x2890e70
objects = 0x7fe5a27f1cf0
stack_limit = 0x300e000
current_thread = 0x28abe00
registers = {{__jmpbuf = {42647040, 80810306853846533, 23377728,
140735361079616, 2308,
42536560, -84392667918189051, -84345635096707579},
__mask_was_saved = 0,
__saved_mask = {__val = {4343230760305832849, 36672864, 36672736,
140624247882320,
36672864, 140624247774144, 140624090466832, 24,
140624246742752, 140624246741380,
21986976, 21986984, 4343230760305832849, 140624247882320,
36672864, 30170752
jump_table_pointer = 0x164b740
jump_table = 0x164b740
#6 0x7fe5a2560158 in really_launch (d=0x7fff81345920) at threads.c:1002
data = 0x7fff81345920
thunk = 0x21801c0
handler = 0x904
t = 0x28abe00
#7 0x7fe5a24eae8a in c_body (d=0x7fe598f58e40) at continuations.c:513
data = 0x7fe598f58e40
#8 0x7fe5a256c427 in vm_debug_engine (vm=0x1cc5e80, program=0x16317e0,
argv=0x7fe598f58d90,
nargs=4) at vm-i-system.c:973
smob = 0x28abe8c
subr = 0x7fe5a2561b60
vp = 0x2890e70
objects = 0x22f9508
stack_limit = 0x300e000
current_thread = 0x28abe00
registers = {{__jmpbuf = {23271392, 8081784237061, 23377728,
140624247304752,
140624090467904, 140624090467904, -84392667825914363,
-84345635096707579},
__mask_was_saved = 0, __saved_mask = {__val = {0, 6, 128, 524288,
140624244487166,
524288, 140624246741380, 6, 32768, 16, 140624246742752,
140624246741380, 1,
140624090467904, 140624244488924, 30170752
jump_table_pointer = 0x164b740
jump_table = 0x164b740
#9 0x7fe5a24f0623 in scm_call_4 (proc=0x16317e0, arg1=,
arg2=, arg3=, arg4=)
at eval.c:512
args = {0x404, 0x22f9560, 0x22f9540, 0x22f9520}
#10 0x7fe5a24eb603 in scm_i_with_continuation_barrier (body=0x7fe5a24eae80
,
body_data=0x7fe598f58e40, handler=0x7fe5a24eb230 ,
handler_data=0x7fe598f58e40,
pre_unwind_handler=, pre_unwind_handler_data=)
at continuations.c:451
stack_item = 22102448
thread = 0x28abe00
old_controot = 0x1cc5ec0
old_contbase = 0x7fe598f58eac
result = 0xfe00
#11 0x7fe5a24eb6b5 in scm_c_with_continuation_barrier (func=,
data=) at continuations.c:547
c_data = {func = 0x7fe5a25600b0 , data = 0x7fff81345920,
result = 0x7fff81345920}
#12 0x7fe5a255f99a in with_guile_and_parent (base=0x7fe598f58ea0,
data=)
at threads.c:903
res =
new_thread = 1
t = 0x28abe00
args = 0x7fe598f58ec0
__PRETTY_FUNCTION__ = "with_guile_and_parent"
#13 0x7fe5a22408d5 in GC_call_with_stack_base (fn=,
arg=) at misc.c:1535
dummy = 0
base = {mem_base = 0x7fe598f58eac}
#14 0x7fe5a255f5bc in scm_i_with_guile_and_parent (d=)
at threads.c:946
args = {func = 0x7fe5a25600b0 , data = 0x7fff81345920,
parent = 0x15141b0}
#15 launch_thread (d=) at threads.c:1014
data = 0x7fff81345920
#16 0x7
Re: Build Error in Master
This problem went away for me when I made distclean and built the most
recent master. I don't know why that fixed it.
2012/3/9 Ludovic Courtès :
> Hi Noah!
>
> Noah Lavine skribis:
>
>> When building the latest git master, I get this error:
>>
>> GUILEC language/tree-il/compile-glil.go
>> Assertion failed: (table->n_items < size), function rob_from_rich,
>> file weak-table.c, line 252.
>
> I’m seeing that too sometimes when running ./check-guile, with this
> backtrace (for all threads):
>
> --8<---cut here---start->8---
> Core was generated by `/data/src/guile-2.1/libguile/.libs/guile --debug
> --no-auto-compile -e main -s /'.
> Program terminated with signal 6, Aborted.
> #0 0x7fe5a0a7e85e in raise ()
> from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
>
> Thread 6 (Thread 8050):
> #0 0x7fe5a20155ac in pthread_cond_wait@@GLIBC_2.3.2 ()
> from
> /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
> No symbol table info available.
> #1 0x7fe5a25601bb in scm_pthread_cond_wait (cond=0x28abe88,
> mutex=0x23d4370)
> at threads.c:1986
> res = -512
> t = 0x28abe00
> #2 0x7fe5a25606d8 in block_self (queue=0x1c4c610, sleep_object= optimized out>,
> mutex=0x23d4370, waittime=0x0) at threads.c:451
> t = 0x28abe00
> q_handle = 0x1e173c0
> err =
> #3 0x7fe5a2560d43 in fat_mutex_unlock (mutex=0x1c4c690, cond=0x1c4c620,
> waittime=0x0,
> relock=1) at threads.c:1627
> brk = 0
> owner = 0x1cc5ed0
> m = 0x23d4370
> c = 0x1bb20c0
> t = 0x28abe00
> err =
> ret =
> #4 0x7fe5a2560ef9 in scm_timed_wait_condition_variable (cv=0x1c4c620,
> mx=0x1c4c690, t=0x904)
> at threads.c:1811
> waittime = {tv_sec = 47438496, tv_nsec = 140624247786400}
> waitptr =
> #5 0x7fe5a256c14f in vm_debug_engine (vm=0x1cc5e80, program=0x21801c0,
> argv=0x0, nargs=0)
> at vm-i-system.c:911
> subr = 0x7fe5a2560e90
> vp = 0x2890e70
> objects = 0x7fe5a27f1cf0
> stack_limit = 0x300e000
> current_thread = 0x28abe00
> registers = {{__jmpbuf = {42647040, 80810306853846533, 23377728,
> 140735361079616, 2308,
> 42536560, -84392667918189051, -84345635096707579},
> __mask_was_saved = 0,
> __saved_mask = {__val = {4343230760305832849, 36672864, 36672736,
> 140624247882320,
> 36672864, 140624247774144, 140624090466832, 24,
> 140624246742752, 140624246741380,
> 21986976, 21986984, 4343230760305832849, 140624247882320,
> 36672864, 30170752
> jump_table_pointer = 0x164b740
> jump_table = 0x164b740
> #6 0x7fe5a2560158 in really_launch (d=0x7fff81345920) at threads.c:1002
> data = 0x7fff81345920
> thunk = 0x21801c0
> handler = 0x904
> t = 0x28abe00
> #7 0x7fe5a24eae8a in c_body (d=0x7fe598f58e40) at continuations.c:513
> data = 0x7fe598f58e40
> #8 0x7fe5a256c427 in vm_debug_engine (vm=0x1cc5e80, program=0x16317e0,
> argv=0x7fe598f58d90,
> nargs=4) at vm-i-system.c:973
> smob = 0x28abe8c
> subr = 0x7fe5a2561b60
> vp = 0x2890e70
> objects = 0x22f9508
> stack_limit = 0x300e000
> current_thread = 0x28abe00
> registers = {{__jmpbuf = {23271392, 8081784237061, 23377728,
> 140624247304752,
> 140624090467904, 140624090467904, -84392667825914363,
> -84345635096707579},
> __mask_was_saved = 0, __saved_mask = {__val = {0, 6, 128, 524288,
> 140624244487166,
> 524288, 140624246741380, 6, 32768, 16, 140624246742752,
> 140624246741380, 1,
> 140624090467904, 140624244488924, 30170752
> jump_table_pointer = 0x164b740
> jump_table = 0x164b740
> #9 0x7fe5a24f0623 in scm_call_4 (proc=0x16317e0, arg1= out>,
> arg2=, arg3=, arg4= optimized out>)
> at eval.c:512
> args = {0x404, 0x22f9560, 0x22f9540, 0x22f9520}
> #10 0x7fe5a24eb603 in scm_i_with_continuation_barrier
> (body=0x7fe5a24eae80 ,
> body_data=0x7fe598f58e40, handler=0x7fe5a24eb230 ,
> handler_data=0x7fe598f58e40,
> pre_unwind_handler=, pre_unwind_handler_data= optimized out>)
> at continuations.c:451
> stack_item = 22102448
> thread = 0x28abe00
> old_controot = 0x1cc5ec0
> old_contbase = 0x7fe598f58eac
> result = 0xfe00
> #11 0x7fe5a24eb6b5 in scm_c_with_continuation_barrier (func= optimized out>,
> data=) at continuations.c:547
> c_data = {func = 0x7fe5a25600b0 , data = 0x7fff81345920,
> result = 0x7fff81345920}
> #12 0x7fe5a255f99a in with_guile_and_parent (base=0x7fe598f58ea0,
> data=)
> at threads.c:903
> res =
> new_thread = 1
> t = 0x28abe00
> args = 0x7fe598f58ec0
> __PRETTY_FUNCTION__ = "with_guile_and_parent"
> #13 0x7fe5a22408d5
