Hi,
The ‘set-pointer-finalizer!’ procedure is harmful because it erases any
previously set finalizer.
Said finalizer could come from a guardian:
(define ptr (make-pointer 123))
(define g (make-guardian))
(g ptr)
(set-pointer-finalizer! ptr (dynamic-func "scm_is_pair" (dynamic-link)))
This was eventually fixed by commit
e1fbe716e8596b7027af57623ebc72a0c6393187 (“fix hook invocation during
thread guilification”).
Thanks!
Ludo’.
Hi!
I’m testing this patch:
diff --git a/libguile/gc.c b/libguile/gc.c
index 7816801..97dfcd8 100644
--- a/libguile/gc.c
+++ b/libguile/gc.c
@@ -730,14 +730,17 @@ queue_after_gc_hook (void * hook_data SCM_UNUSED,
if (scm_debug_cells_gc_interval == 0)
#endif
{
- scm_i_thread *t = SCM
On Mon 30 Jan 2012 16:26, l...@gnu.org (Ludovic Courtès) writes:
> #0 queue_after_gc_hook (hook_data=, fn_data= optimized out>,
> data=) at gc.c:737
> #1 0x7f236ea0518c in scm_c_hook_run (hook=0x7f236ed00a10, data=0x0) at
> hooks.c:103
> #2 0x7f236e729951 in GC_notify_full_gc (stop
Hi!
I’ve just captured the following backtrace on x86_64-linux-gnu (with
v2.0.3-212-g2f3e436):
--8<---cut here---start->8---
Core was generated by `/home/ludo/soft/bin/guile -e (@@ (guild) main) -s
/home/ludo/soft/bin/guile-too'.
Program terminated with signa
Not really a bug per se (although the manual states that "When Guile
hangs or takes forever to complete a task, it is a bug."), but the time
complexity behind the compilation of (or ...) patterns in (ice-9 match)
module is so high that anything more than 8 sub-patterns takes forever
for me. Here i
