Re: [PATCH]: deadlock in make_struct()
Linas Vepstas escreveu: > 2008/11/17 Andy Wingo <[EMAIL PROTECTED]>: >> Hi Linas, >> >> I was about to write about how your patch looked incorrect to me, >> because GC could see a half-initialized struct (and potentially sweep >> it, with a bad free function); > > Well, I tried to think that through. I tried to find a need for a > "remember_up_to_here", but it didn't look like the code > needed it -- it seemed like everything was on stack or > in registers, and so would be safe from accidental GC. Our GC is lazy; if a function momentarily drops a reference, you´d have to have 2 GCs within the same function body to see bad effects. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: [PATCH] Final: thread lock nesting debugging
Linas Vepstas escreveu: > I've been seeing all sorts of deadlocks in guile, and so I wrote a small > debugging utility to try to track down the problems. I'd like to see > this patch included in future versions of guile. > > I found one bug with this tool, and have submitted a patch for that > already. It looks like there's another bug involving signals -- > there is a probably deadlock in garbage collection if a signal > is sent at just the wrong time. The bug can be seen by enabling > this patch, and then running 'make check'. I'm going to ignore > this, as I'm not worried about signals right now. > > This is my "final" version of this patch, I'd sent a beta version > a few days ago. Its "final" because I'm not anticipating any > further changes. Would it be possible to have this be a runtime switch? My experience is that conditional code in GUILE (especially the debugging ones) tend to bitrot very quickly. Also, they don´t help anyone who is not compiling their own GUILE. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: Does anyone actually use threads with guile?
Linas Vepstas escreveu: > 2008/11/12 Linas Vepstas <[EMAIL PROTECTED]>: > >> Today, I got a new crash. I have multiple threads, which >> are doing nothing but a bunch of define's, in parallel. >> (They're loading scheme code from various files). > > Studying the code just a little bit more, this looks like > a dopey and pointless error check within guile, > specifically, at libguile/throw.c line 695. > Removing it seems to result in a runable system. Re -the subject- : I looked at the evaluator code from a threading perspective a few months back, and come to the conclusion that it is totally broken. The memoization code rewrites expressions without locking or atomicity, and if you have two threads memoizing (ie. executing the same code for the 1st time), you will have unpredictable effects. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: >>> Can you please restart from there and report back? >> from ../../libguile/scmconfig.h:25, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/__scm.h:52, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile.h:30, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/test-suite/standalone/test-asmobs-lib.c:18: >> ../../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' >> ../../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' >> make[4]: ** [libtest_asmobs_la-test-asmobs-lib.lo] Erro 1 >> make[4]: Saindo do diretório `/home/lilydev/vc/gub/target/mingw/build/gui > > Of course, I had forgotten the tests. I'm not sure I understand, though. Shouldn't the tests use the public interface (of which lib/*.h surely isn't part?) -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: > OK, I reviewed all C files and noticed that most of them did not include > , even those that clearly use `HAVE_' macros, or `inline', > etc., which is clearly likely to cause problems. The problems are even > more likely to show up since we use Gnulib headers that most of the time > rely on macros. Thus, I committed the attached patch to > `master' and a similar one in 1.8. > > Can you please restart from there and report back? from ../../libguile/scmconfig.h:25, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/__scm.h:52, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile.h:30, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/test-suite/standalone/test-asmobs-lib.c:18: ../../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' ../../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' make[4]: ** [libtest_asmobs_la-test-asmobs-lib.lo] Erro 1 make[4]: Saindo do diretório `/home/lilydev/vc/gub/target/mingw/build/gui -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: > Hi, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> adding the include to srfi-4.c, I still get >> >> i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H -DSCM_IMPORT -I. -I.. >> -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi >> -I.. >> -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/.. >> >> -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/lib >> -I../lib -Wall -Wmissing-prototypes -g -O2 -MT srfi-1.lo -MD -MP -MF >> .deps/srfi-1.Tpo -c >> /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/srfi-1.c >> -DDLL_EXPORT -DPIC -o .libs/srfi-1.o > > Hmm, that's `srfi-1.c', not `srfi-4.c'. > >> In file included from >> /home/lilydev/vc/gub/target/mingw/root/usr/include/sys/time.h:3, >> from ../libguile/scmconfig.h:25, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../libguile/__scm.h:52, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../libguile.h:30, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../srfi/srfi-4.h:25, >> from >> /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/srfi-4.c:25: >> ../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' >> ../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' >> make[3]: ** [srfi-4.lo] Erro 1 > > OK, I reviewed all C files and noticed that most of them did not include > , even those that clearly use `HAVE_' macros, or `inline', > etc., which is clearly likely to cause problems. The problems are even > more likely to show up since we use Gnulib headers that most of the time > rely on macros. Thus, I committed the attached patch to > `master' and a similar one in 1.8. As a review comment: is there a specific reason to do HAVE_CONFIG_H ? In what case do we not HAVE_CONFIG_H ? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: > Hi, > > [EMAIL PROTECTED] (Ludovic Courtès) writes: > >> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >> >>> In file included from >>> /home/lilydev/vc/gub/target/mingw/root/usr/include/sys/time.h:3, >>> from ../libguile/scmconfig.h:25, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/__scm.h:52, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile.h:30, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/discouraged.c:22: >>> ../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' >>> ../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' >> Reported here: >> >> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/14574 > > Actually, as suggested by Eric Blake, this is probably fixed by the > attached patch (committed). Can you confirm it? adding the include to srfi-4.c, I still get i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H -DSCM_IMPORT -I. -I.. -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi -I.. -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/.. -I/home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/lib -I../lib -Wall -Wmissing-prototypes -g -O2 -MT srfi-1.lo -MD -MP -MF .deps/srfi-1.Tpo -c /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/srfi-1.c -DDLL_EXPORT -DPIC -o .libs/srfi-1.o In file included from /home/lilydev/vc/gub/target/mingw/root/usr/include/sys/time.h:3, from ../libguile/scmconfig.h:25, from /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../libguile/__scm.h:52, from /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../libguile.h:30, from /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/../srfi/srfi-4.h:25, from /home/lilydev/vc/gub/target/mingw/src/guile-localhost--home-lilydev-vc-guile-master/srfi/srfi-4.c:25: ../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' ../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' make[3]: ** [srfi-4.lo] Erro 1 -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: >>> In file included from >>> /home/lilydev/vc/gub/target/mingw/root/usr/include/sys/time.h:3, >>> from ../libguile/scmconfig.h:25, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/__scm.h:52, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile.h:30, >>> from >>> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/discouraged.c:22: >>> ../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' >>> ../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' >> Reported here: >> >> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/14574 > > Actually, as suggested by Eric Blake, this is probably fixed by the > attached patch (committed). Can you confirm it? It now barfs similarly on gh_eval.c; this looks like a good moment to drop the GH interface. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: > Hi, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H >> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git -I.. >> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/lib -I../lib -Wall >> -Wmissing-prototypes -g -O2 -MT libguile_i18n_v_0_la-i18n.lo -MD -MP -MF >> .deps/libguile_i18n_v_0_la-i18n.Tpo -c >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c >> -DDLL_EXPORT -DPIC -o .libs/libguile_i18n_v_0_la-i18n.o >> In file included from >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c:296: >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h: >> In function 'get_current_locale_settings': >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: 'LC_MESSAGES' undeclared (first use in this function) >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: (Each undeclared identifier is reported only once >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: for each function it appears in.) > > Can you try out the attached patch? Seems to work. Next problem: In file included from /home/lilydev/vc/gub/target/mingw/root/usr/include/sys/time.h:3, from ../libguile/scmconfig.h:25, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/__scm.h:52, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile.h:30, from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/discouraged.c:22: ../lib/time.h:76: error: expected ';', ',' or ')' before '__timer' ../lib/time.h:78: error: expected ';', ',' or ')' before '__timer' This is 7ddb9baf80744f0ea4810c35b465d96f4833875, with your patch on top. Curiously, the same location in uncompiled source (my guile devel directory) has an #if 0 rather than #if 1 around the code. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: i18n broken on mingw cross compile
Ludovic Courtès escreveu: > Hi, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H >> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git -I.. >> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/lib -I../lib -Wall >> -Wmissing-prototypes -g -O2 -MT libguile_i18n_v_0_la-i18n.lo -MD -MP -MF >> .deps/libguile_i18n_v_0_la-i18n.Tpo -c >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c >> -DDLL_EXPORT -DPIC -o .libs/libguile_i18n_v_0_la-i18n.o >> In file included from >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c:296: >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h: >> In function 'get_current_locale_settings': >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: 'LC_MESSAGES' undeclared (first use in this function) >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: (Each undeclared identifier is reported only once >> /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: >> error: for each function it appears in.) > > Can you try out the attached patch? > I'll try later; in the meantime, I suspect that surrounding every one of the locale categories with #ifdef would be a good idea. I'd be surprised if this were the only one missing. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
i18n broken on mingw cross compile
This is with 289cd1a720edb522ea60d7dfd0f1f4763284f050 i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git -I.. -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/lib -I../lib -Wall -Wmissing-prototypes -g -O2 -MT libguile_i18n_v_0_la-i18n.lo -MD -MP -MF .deps/libguile_i18n_v_0_la-i18n.Tpo -c /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c -DDLL_EXPORT -DPIC -o .libs/libguile_i18n_v_0_la-i18n.o In file included from /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/i18n.c:296: /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h: In function 'get_current_locale_settings': /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: error: 'LC_MESSAGES' undeclared (first use in this function) /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: error: (Each undeclared identifier is reported only once /home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/libguile/locale-categories.h:24: error: for each function it appears in.) does this ring a bell with anyone? This was working with release_1-8-5 -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
configure doesn't check for clog and csqrt
Apparently, in GUILE-1.8.1 configure doesn't check for clog and csqrt(). This leads to problems on Freebsd 4.1, as the libc there doesn't support both functions. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
bug in scm_put[sc]
hi, scm_put[cs] do not check whether their arguments are ports, but crash randomly instead when this is not the case. IMO, this is a bug. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
list-index overloaded
list-index is defined in boot-9.scm, but its signature does not
correspond to the srfi-1 function. I consider this a bug.
guile> list-index
#
guile> (help list-index)
No documentation found for:
(guile): list-index
guile> (use-modules (srfi srfi-1))
guile> list-index
#
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Serious GC bug in GUILE 1.6 CVS
[EMAIL PROTECTED] writes: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > > Compile GUILE with > > > > #define SCM_DEBUG_CELL_ACCESSES 1 > > > > in config.h. Then apply this patch > > > > + (set-debug-cell-accesses! 5000) > > > > then compilation bombs out with: > > I have found the bug. init_heap_seg was using SCM_SET_CELL_TYPE to > initialize fresh memory to 'free cells', but with DEBUG_CELL_ACCESSES, > SCM_SET_CELL_TYPE could run a GC, which might see the half initialized > heap segment during conservative scanning and would access > uninitialozed memory which caused it to fail. > > I have fixed this by using the new macro SCM_SET_FREE_CELL_TYPE, which > does no checking. Hmm... That's unfortunate. We have reports of GC flakiness with 1.6 on Cygwin. This means that there's still another bug lurking. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Serious GC bug in GUILE 1.6 CVS
Compile GUILE with
#define SCM_DEBUG_CELL_ACCESSES 1
in config.h. Then apply this patch
*** snarf-check-and-output-texi.~1.2.2.8.~ 2002-07-20 23:14:53.0
+0200
--- snarf-check-and-output-texi 2004-08-17 23:02:54.246192464 +0200
***
*** 25,30
--- 25,31
;;; Author: Michael Livshin
;;; Code:
+ (set-debug-cell-accesses! 5000)
(define-module (scripts snarf-check-and-output-texi)
:use-module (ice-9 streams)
then compilation bombs out with:
cat alist.doc [..] |
GUILE="/home/hanwen/usr/src/savannah/official-guile/stable/guile/guile-core/pre-inst-guile"
../scripts/snarf-check-and-output-texi --manual > guile.texi || { rm
guile.texi; false; } Error in scm_gc_mark during GC: rogue pointer in
heap make: *** [guile.texi] Fout 1
This is on fedora core3 test1, Linux 2.6.7
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile
debugging line numbers are off
byrd:~/usr/src/lilypond$ guile guile> ,1 Backtrace: In standard input: 1048576: 0* (unquote 1) standard input:1048576:4096: In expression (unquote 1): standard input:1048576:4096: Unbound variable: unquote ABORT: (unbound-variable) guile> -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: stack overflow bug
[EMAIL PROTECTED] writes: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > > Can you please fix this? I consider this a severe bug. > > Done! Thanks. cool > PS: A workaround is to use 'quote': > > (eval `(bar ',q) (current-module)) We figured that out a few days later. But thanks for looking at this. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
assoc-remove!
guile> (assoc-remove! 'foo ' (1 2 )) foo IMO, this should raise an error, since the 1st argument to assoc-remove should be an alist. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
stack overflow bug
This is current CVS guile> (define q (open-file "foo" "w")) guile> (define (bar b) b) guile> (eval `(bar ,q) (current-module)) ERROR: Stack overflow ABORT: (stack-overflow) guile> (version) "1.7.0" GUILE goes into infinite recursion while calling SCM_SMOB_APPLY_3 (line 4163, eval.c) which seems to be related to the port object. Can you please fix this? I consider this a severe bug. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
pointer to ?
in list.c, many doc strings say
"Return a pointer to\n"
"the mutated list."
"Return a pointer to the last pair in @var{lst},"
isn't this stupid? Scheme doesn't have pointers. Why not say
"Return the last pair in lst"
"Return the mutated list."
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: core dump.
[EMAIL PROTECTED] writes: > Please try again, I think I have fixed it: Thanks for your quick reply. It seems to be working. There was a stray variable in eval.c, though. I fixed that. BTW, how is GUILE 1.8 progressing? Have you considered switching to a time-based release schedule, like GNOME and RedHat^H^H^H^H^H^H Fedora do? I would really like to use rational support in LilyPond. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: core dump.
[EMAIL PROTECTED] writes: > > [Switching to Thread 1074493760 (LWP 27557)] > > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > (gdb) bt > > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469 > > I've seen something like this when an error (an ordinary scheme level > error) occurs in code generated by a procedure->macro. Dunno if > that's what's happening here. Running without --debug normally avoids > the segv (though obviously one can't tell quite where it went wrong). Yeah, I found out so far. Now I have to figure out what in my 1 lines of Scheme code is causing ERROR: In procedure car: ERROR: Wrong type argument in position 1: () Does anyone actually know how the evaluator works? -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
--help
http://www.gnu.org/prep/standards_18.html#SEC18: Near the end of the `--help' option's output there should be a line that says where to mail bug reports. It should have this format: Report bugs to mailing-address. GUILE CVS fails this. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
core dump.
hi,
I have a nasty coredump; this is with fairly recent CVS (ChangeLog
timestamp 26/12). Any thoughts? This is from within LilyPond. The
only funky thing was that the file was doing some operations with a
trivial GOOPS class. Any ideas?
elapsed time: 0.01 secondsBacktrace:
In c.ly:
2: 0* [determine-split-list #(# # # # ...) #(# # # #)]
In unknown file:
?: 1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074493760 (LWP 27557)]
0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
(gdb) bt
#0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
#1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469
#2 0x4002f640 in scm_unmemocopy (x=0x404da7e0, env=0x4050de58) at eval.c:2468
#3 0x4002fadc in scm_unmemocopy (x=0x404da7d8, env=0x4050de58) at eval.c:2457
#4 0x4002f640 in scm_unmemocopy (x=0x404da778, env=0x4050de58) at eval.c:2468
#5 0x4002f640 in scm_unmemocopy (x=0x404dcad0, env=0x4050de58) at eval.c:2468
#6 0x4002f640 in scm_unmemocopy (x=0x404f4e00, env=0x4050e3f8) at eval.c:2468
#7 0x4002fa59 in scm_unmemocopy (x=0x404f4df0, env=0x4050e3f8) at eval.c:2366
#8 0x400261c0 in scm_unmemoize (m=0x167f) at debug.c:282
#9 0x40022cd7 in display_frame (frame=0x4050e408, nfield=1, indentation=1,
sport=0x40507020, port=0x402ca0f0, pstate=0x829a520) at backtrace.c:621
#10 0x40022fd1 in display_backtrace_body (a=0xbfffde00) at backtrace.c:728
#11 0x4006ea85 in scm_internal_catch (tag=0x37c,
body=0x40022d78 , body_data=0xbfffde00,
handler=0x400222c4 , handler_data=0xbfffddf8)
at throw.c:172
#12 0x400231bf in scm_display_backtrace (stack=0x167f, port=0x0, first=0x167f,
depth=0x167f) at backtrace.c:758
#13 0x4006ef55 in handler_message (handler_data=0x0, tag=0x824ce60,
args=0x405070e0) at throw.c:401
#14 0x4006efda in scm_handle_by_message (handler_data=0x0, tag=0x824ce60,
args=0x405070e0) at throw.c:452
#15 0x4006f234 in scm_ithrow (key=0x824ce60, args=0x405070e0, noreturn=1)
at throw.c:597
#16 0x4002c05d in scm_error (key=0x824ce60, subr=0x0, message=0x0,
args=0x40507118, rest=0x17c) at error.c:71
#17 0x4002d203 in error_unbound_variable (symbol=0x406e46f0) at eval.c:550
#18 0x4002d2e9 in scm_lookupcar1 (vloc=0x404d8308, genv=0x40507120, check=1)
at eval.c:691
#19 0x400369c1 in scm_deval (x=0x404d8308, env=0x40507120) at eval.c:3626
#20 0x400361ec in scm_deval (x=0x404da2d0, env=0x40507230) at eval.c:3936
#21 0x400362fc in scm_deval (x=0x404da2c8, env=0x40507230) at eval.c:3799
#22 0x40035389 in scm_deval (x=0x404da2b0, env=0x40507230) at eval.c:3244
#23 0x4003437c in scm_deval (x=0x404da2a8, env=0x40507230) at eval.c:2962
#24 0x4003437c in scm_deval (x=0x404dc788, env=0x404f4db8) at eval.c:2962
#25 0x40033967 in scm_i_eval (exp=0x167f, env=0x404f5090) at eval.c:5405
#26 0x40033a0a in scm_primitive_eval (exp=0x404f5270) at eval.c:5429
#27 0x080fd363 in internal_ly_parse_scm (ps=0xbfffe710) at parse-scm.cc:32
#28 0x080fd3d1 in catch_protected_parse_body (p=0xbfffe710) at parse-scm.cc:71
#29 0x4006ea85 in scm_internal_catch (tag=0x406dd1b0,
body=0x80fd3ba , body_data=0xbfffe710,
handler=0x80fd3d6 , handler_data=0xbfffe710) at throw.c:172
#30 0x080fd4f1 in protected_ly_parse_scm (ps=0xbfffe710) at parse-scm.cc:108
#31 0x080fd53e in ly_parse_scm (
s=0x82f2a61 "(determine-split-list (car noticed) (cadr noticed))\n \n",
n=0xbfffe87c, i=
{defined_str0_ = 0x82f2a61 "(determine-split-list (car noticed) (cadr
noticed))\n \n", source_file_ = 0x8356858}) at parse-scm.cc:127
#32 0x08175bfc in My_lily_lexer::yylex() (this=0x83558f8) at lexer.ll:294
#33 0x0817a4d5 in yylex (s=0xb118, v=0xb200) at parser.yy:230
#34 0x0817a73d in yyparse (my_lily_parser=0xb200) at out/parser.cc:2119
#35 0x08184857 in My_lily_parser::do_yyparse() (this=0xb200)
at parser.yy:2321
#36 0x080e5798 in My_lily_parser::parse_file(String, String, String) (
this=0xb200, init={strh_ = {data = 0x8354f50}}, in_file=
{strh_ = {data = 0x8354f68}}, out_file={strh_ = {data = 0x8354f38}})
at my-lily-parser.cc:49
#37 0x080b26a2 in Input_file_results (this=0xb290, init=
{strh_ = {data = 0x8354f50}}, in_file={strh_ = {data = 0x8354f68}},
out_file={strh_ = {data = 0x8354f38}}) at input-file-results.cc:142
#38 0x080b2ea9 in do_one_file (init={strh_ = {data = 0x8354f50}}, in_file=
{strh_ = {data = 0x8354f68}}, out_file={strh_ = {data = 0x8354f38}})
at input-file-results.cc:171
#39 0x080cb832 in main_prog () at main.cc:370
#40 0x40048d68 in invoke_main_func (body_data=0x167f) at init.c:600
#41 0x40048d23 in scm_boot_guile_1 (base=0xb43c, closure=0xb440)
at init.c:580
#42 0x40048a1b in scm_boot_guile (argc=5759, argv=0x167f, main_func=0x167f,
closure=0x167f) at init.c:392
#43 0x080cbff2 in main (argc=3, argv=0xb564) at main.cc:499
(gdb)
--
Han-Wen Nienhuys | [EMAIL P
bugreport, concise version
Hi guys, I consider this a very severe bug. Can you fix this please? byrd:~/usr/src/lilypond$ guile -l scm/bla.scm Backtrace: In unknown file: ?: 0* [primitive-load "scm/bla.scm"] In scm/bla.scm: 107: 1* [determine-split-list #((1 . 2) (3 . 4)) #((1 . 2) (3 . 4))] In unknown file: ?: 2 Segmentatie fout bla.scm : (define ly:momentvector (map (lambda (x) (cons x 'together)) (merge (map car ev1) (map car ev2) ly:moment (length notes1) 1) (put 'apart)) ((> (length notes2) 1) (put 'apart)) (else (let* ((dif (ly:pitch-diff (car pitches1) (car pitches1 (if (< (ly:pitch-steps diff) chord-threshold) (put 'chords) (put 'apart)) )) (analyse-events (1+ i1) (1+ i2) (1+ ri) active1 active2) ) (set! ev1 (list->vector ev1)) (set! ev2 (list->vector ev2)) (analyse-events 0 0 0 '() '()) (display result) ) (determine-split-list '((1 . 2) (3 . 4)) '((1 . 2) (3 . 4))) -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
typo
http://www.gnu.org/software/guile/developers.html says "Reporing bugs" -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
wrong error?
Is this intentional ? I'd expect "wrong type to apply".
guile> ("" . "")
standard input:2:1: In expression ("" . ""):
standard input:2:1: Wrong number of arguments to
ABORT: (wrong-number-of-args)
--
Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: port?
[EMAIL PROTECTED] writes: > > From: Han-Wen Nienhuys <[EMAIL PROTECTED]> > > Date: Sun, 22 Oct 2000 01:01:38 +0200 > > > > is there a reason why (port?) is not in guile-1.4? > > Inherited from R5RS. You can make your own: I don't understand. On page 6 R5RS mentions port?, suggesting it should be in. -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
port?
is there a reason why (port?) is not in guile-1.4? -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
sloppy_memq docstring.
in guile 1.4 it says.
"This procedure behaves like @code{memq}, but does no type or error
this is not true: memq returns '() if nothing is found, not #f.
--
Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
compile on redhat 7
I get this. gcc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -g -O2 -Wall -Wmissing-prototypes -c net_db.c -fPIC -DPIC -o .libs/net_db.lo net_db.c:85: conflicting types for `inet_aton' /usr/include/arpa/inet.h:69: previous declaration of `inet_aton' -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/ ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
mohre warts
I believe i didn't report this earlier: gcc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -I./../gc/ -I./../gc/include -g -O2 -Wall -Wmissing-prototypes -Wp,-MD,.deps/modules.pp -c modules.c -fPIC -DPIC -o .libs/modules.lo modules.c: In function `module_variable': modules.c:200: warning: passing arg 1 of `scm_hashq_ref' makes pointer from integer without a cast modules.c:204: warning: initialization makes pointer from integer without a cast modules.c:217: warning: initialization makes pointer from integer without a cast modules.c: In function `scm_standard_eval_closure': modules.c:248: warning: passing arg 2 of `scm_makcclo' makes integer from pointer without a cast -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/
wart
another one: the name free is confusing (from gc.c) scm_struct_free_t free = (scm_struct_free_t) vtable_data[scm_struct_i_free]; m += free (vtable_data, (scm_bits_t *) SCM_UNPACK (SCM_GCCDR (scmptr))); -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu.nl/~hanwen/
another nit.
why do assq-ref and friends return #f when the key is not found, in stead of #? This makes it kind of hard to distinguish between an alist not containing KEY and (KEY . #f) -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu/~hanwen/
stdio.h ?
Is there any reason why gh.h includes stdio.h? If no, could this be removed? -- Han-Wen Nienhuys | [EMAIL PROTECTED]| http://www.cs.uu/~hanwen/
typedef void * SCM
Hi, just a minor final nit. Can SCM_VOIDP_TEST be enabled by default? And can the definition of SCM be changed to typedef struct UNUSED_STRUCT * SCM; (or perhaps scm_cell in stead of UNUSED_STRUCT; that might ease debugging a little in some cases). C compiler cast from and to void * without complaints, which fucks up compatibility if you have a C++ program that has both one from func (const char *); func (String); func (void*); and func (SCM ); -- Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter http://www.cs.uu.nl/people/hanwen/lilypond/index.html
