A couple of bug status updates.

[bpt/guile.git] / BUGS

BUGS

This file contains bugs we haven't fixed yet, and some we have.
The format is very simple (one bug per page):

#   line                                   regexp

1   bug NUMBER -- ONE-LINE-DESCRIPTION     ^bug ([0-9]+) -- (.+)$
2   reported-by: SOMEONE / DATE            ^reported-by: ([^/]) */ *(.+)$
3   fixed: DATE (for guile VERSION)        ^fixed: (.+) .for guile (.+).$
4+  OTHER-NOTES

DATE is formatted YYYY-MM-DD, or "not-yet".  Line numbering is zero-origin;
line 0 is empty (newline always follows newpage (recognizable w/ "\f\n")).
The suggested regexps can be used in a line-oriented parser.

You can use "fixed: no-need (EXPLANATION)" if the bug doesn't need to be
fixed.  EXPLANATION might be "not a bug", "user error", etc.

\f
bug 0 -- no BUGS file
reported-by: ttn / 2001-09-25
fixed: 2001-09-30 (1.5.x, 1.7.x)

bugs are good.

\f
bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile
reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31
fixed: 2001-11-07 (1.7.x)

ttn sez:
buggy behavior confirmed on both 1.5.x and 1.7.x.

on the other hand, when second or later, the expected effect (disabling use of
debugging evaluator) seems to be reflected when viewing the debug options.  it
could be that the bug is in display and not the actual setting.

NJ 2002-03-08:

Problem was caused by (top-repl)'s loading of (ice-9 debug), which
ended with unconditional `(debug-enable 'debug)'.  Fixed by removing
the offending lines.

\f
bug 2 -- documentation mirroring not complete
reported-by: lord@regexps.com / 2001-08
fixed: not-yet

ttn sez:
uncollated mirroring is already available:
http://savannah.gnu.org/cgi-bin/viewcvs/guile/
http://mail.gnu.org/pipermail/guile-devel/

\f
bug 3 -- design decisions not recorded
reported-by: lord@regexps.com / 2001-08
fixed: not-yet

changes are made w/ little documentation on their motivation, design and
consequences.  past initiatives and current maintainer discipline to support
them need shoring up.

ttn sez:
someone also mentioned that process and product are orthogonal; nastiness can
result in/from either, and for different reasons.  i tend to believe this up
until a certain point, when the process becomes self-aware and includes its own
improvement in its considerations.  then, hopefully it becomes light.

to change people is difficult, but that's why we have guile...

\f
bug 4 -- named-let transform evaluates initvalue in the wrong scope
reported-by: agj@alum.mit.edu / 2001-09-21
fixed: 2001-11-17 (1.7.x)

currently:
> (let name ((var init) ...) body ...)
>
> to
>
> (letrec ((name (lambda (var ...) body ...)))
>   (name init ...))

should be:
> ((letrec ((name (lambda (var ...) body ...))) name) init ...)

Dirk Herrmann sez:
I will do it - no big deal (I hope).  But, I won't have time to do it
before next week.  What about adding this code as a test case to the test
suite?  Until it is fixed, it can be tagged as expected to fail.

\f
bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification
reported-by: kwright@gis.net / 2001-10-07
fixed: 2001-10-14 (1.5.x, 1.7.x)

Keith Wright sez:
> Before getting into philosophy, I want to mention that while poking
> around and rethinking I found the following Bug.
>
>     guile> (version)
>     "1.5.2"
>     guile> #E3
>     3
>     guile> #e3
>     ERROR: read:uniform-vector list not found
>     ABORT: (misc-error)
>     guile> 3
>
> This violates both R5RS 7.1 ``Case is insignificant'' and
>
> > From: guile-1.5.2/doc/ref/guile.info-3 Line 568
> >
> >     The codes for indicating exactness (which can, incidentally, be
> >  applied to all numerical values) are:
> >
> >   * `#e', `#E' -- the number is exact

2001-10-14  Mikael Djurfeldt  <mdj@linnaeus>

        * read.c (scm_lreadr): When user-defined hash procedure returns
        SCM_UNSPECIFIED: Fall back to standard handling instead of raising
        an exception.  (This prevents parsing of uniform vectors from
        interfering with parsing of numbers.)

\f
bug 6 -- exactness prefix doesn't do nothing gracefully
reported-by: kwright@gis.net / 2001-10-09
fixed: 2001-10-14 (1.5.x, 1.7.x) (see bug 5)

[this may be related to bug 5. --ttn]

Keith Wright sez:
> The saga continues...
>
> > >     The codes for indicating exactness (which can, incidentally, be
> > >  applied to all numerical values) are:
> > >
> > >   * `#e', `#E' -- the number is exact
>
>   guile> #E3  ==>  3
>   guile> #E3.0
>   ERROR: In procedure scm_lreadr:
>   ERROR: unknown # object
>
> Better change the reference manual s/, incidentally,/'t/.
>
> (That's a joke son.  The Scheme language requires #e in front
> of any number to at least do nothing successfully.)

\f
bug 7 -- readline configuration anomolies not handled gracefully
reported-by: kwright@gis.net / 2001-10-17
fixed: not-yet

\f
bug 8 -- install requires makeinfo
reported-by: kwright@gis.net / 2001-10-17
fixed: not-yet

Keith Wright sez:
> I got guile-1.5.4 and installed it on one machine with no problem.
> On another I did ./configure;make as before and it died with:
>
> > ...
> > on.doc vports.doc weaks.doc        symbols-deprecated.doc regex-posix.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.doc | ./guile-snarf-docs-texi > guile.texi \
> > || { rm guile.texi; false; }
> > rm -f guile-procedures.txt
> > makeinfo --force -o guile-procedures.txt guile.texi || test -f guile-procedures.txt
> > /bin/sh: makeinfo: command not found
> > make[1]: *** [guile-procedures.txt] Error 1
> > make[1]: Leaving directory `/home/kwright/build/guile-1.5.4/libguile'
> > make: *** [all-recursive] Error 1
>
> I get the impression that it is supposed to build without 'makeinfo',
> if this is not so it should be mentioned in the README or INSTALL.

NJ 2002-03-08:

Addressed partially in Makefile.am, by copying guile-procedures.texi
to guile-procedures.txt if makeinfo is not available.

However, a better IMO fix would be to include a prebuilt
guile-procedures.txt in the distribution.

\f
bug 9 -- sibling threads not infinite looping
reported-by: giraud@tif.inria.fr / 2001-09-24
fixed: not-yet

Manuel Giraud sez:
> I've configure guile-1.5.4 '--with-threads' and '--with-modules' on a
> "classical" Linux box and used this code that crash silently :
>
> (use-modules (ice-9 threads))
>
> (begin-thread
>  (let loop ()
>    (display "a")
>    (newline)
>    (loop)))
>
> (begin-thread
>  (let loop ()
>    (display "b")
>    (newline)
>    (loop)))

mdj sez:
+ 2001-10-06  Mikael Djurfeldt  <mdj@linnaeus>
+
+       These changes fixes a race condition in the Guile coop - pthread
+       compatibility code.
+
+       * coop.c (mother_awake_p): New variable.
+       (coop_create): Set mother_awake_p before creating or signalling
+       mother; wait until mother is going to sleep before returning.
+       (mother): Reset mother_awake_p before going to sleep.
+

ttn sez:
crash still occurs w/ "guile -s bug.scm" (cvs checkout on 2001/11/06).
however, "guile -l bug.scm" works as expected.

\f
bug 10 -- embedded libltdl masks system version unconditionally
reported-by: grib@linuxdevel.com / 2001-11-04
fixed: not-yet

Bill Gribble sez:
> The guideline for when to use the convenience version of libltdl is
> this:
>
> > In general you can safely use the convenience library in
> > programs which don't depend on other libraries that might
> > use libltdl too.
>
> So guile's use of the convenience library embodies an assumption about
> programs which use guile: that they will not use libltdl except through
> guile's wrapper (dynamic-link and friends).
>
> It seems like this is a bad assumption for guile to make, since it is
> intended to be used as an extension language for many different kinds of
> programs and not to put a priori restrictions on what they can do.
> Especially when those restrictions are not documented.
>
> I would suggest that prior to the guile-1.6 release the use of the
> convenience ltdl library be removed, instead depending on an installed
> version of libltdl.

\f
bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values
reported-by: ttn / 2001-11-09
fixed: no-need (behavior consistent w/ Common Lisp, user error)

ttn sez:
> the following code displays
>
>   (#<procedure good x> ())
>   (#<procedure good x> (1))
>   (#<procedure good x> ((1 2 3)))
>   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY))
>   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY 1))
>   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY (1 2 3)))
>
> but `x' should be the same for both `good' and `blah':
>
>   (use-modules (ice-9 optargs) (ice-9 rdelim))
>
>   (define* (good #:rest x)
>     (write-line (list good x)))
>
>   (good)
>   (good 1)
>   (good '(1 2 3))
>
>   (define* (blah #:key (j 'j) (k 'k) #:rest x)
>     (write-line (list blah j k x)))
>
>   (blah #:j 'JAY #:k 'KAY)
>   (blah #:j 'JAY #:k 'KAY 1)
>   (blah #:j 'JAY #:k 'KAY '(1 2 3))

mvo sez:
> In Common Lisp, there are no non-key rest-args when you have keyword
> parameters.  After the required and optional arguments, there must
> follow an even number of additional arguments, and every two of them
> are treated as a keyword/value pair.
>
> I think it makes sense the way CL specifies this.  Anything beyond
> this would lead to confusion.  If you want to go beyond what (ice-9
> optargs) offers, yo are probably best off writing your own argument
> parser.

\f
bug 12 -- goops class redefinition not signalling "no such accessor" error
reported-by: wawrzin@cs.tu-berlin.de / 2001-12-04
fixed: not-yet

Thomas Wawrzinek sez:
> Running the following script produces some guile output which confueses me:
>
> ;;; script.scm
> (use-modules (oop goops))
>
> (define-class <root> ())
>
> (define-class <foo> (<root>)
>   (a #:init-value #f #:accessor a-value #:init-keyword #:a-value)
>   (b #:init-value #f #:accessor b-value #:init-keyword #:b-value))
>
> (define-class <bar> (<foo>))
>
> (define-method (initialize (o <bar>) . args)
>   (set! (a-value o) "BAR")
>   (next-method))
>
> (define-generic print)
>
> (define-method (print (o <bar>))
>   (display (a-value o)) (newline)
>   (display (b-value o)) (newline))
>
> ;;; OK, this is very *wrong*!
> (define-class <bar> (<root>))
>
> (define baz (make <bar> #:b-value "BAZ"))
>
> (print baz)
>
> $ guile -s script.scm
> BAR
> #<unknown-immediate 0x69746163>
> $ guile -v
> Guile 1.5.4
> Copyright (c) 1995, 1996, 1997, 2000, 2001 Free Software Foundation
> Guile may be distributed under the terms of the GNU General Public Licence;
> certain other uses are permitted as well.  For details, see the file
> `COPYING', which is included in the Guile distribution.
> There is no warranty, to the extent permitted by law.
>
> I'm running on a SuSE Linux 7.2 box ...
>
> I expected that because of the second (define-class <bar> ...) I would get
> some sensible error message (at least about the usage of (a-value ...) in
> the (print ...) generic function call).
>
> Maybe I'm mistaken here, I know that GOOPS has a class redefinition
> protocol, but does it go with the define-class macro?
>
> I accidently had such a second (define-class ...) with an already
> used class-name. In a much more complex program than the above, this
> resulted in a segmentation fault (backtrace told me it was GC related).
>
> To avoid such behavior, would it be sensible to have guile indicate
> a wrong usage error or something?

\f
bug 13 -- incorrect error reporting after stack overflow
reported-by: Panagiotis Vossos <jacbre@internet.gr> / 2002-02-19
fixed: not-yet

Panagiotis Vossos sez:

I have guile 1.5.4 installed and I discovered something strange.

guile> (define (foo n) (+ n (foo n)))
guile> (foo 10)
ERROR: Stack overflow
ABORT: (stack-overflow)
guile> thisisabug
<unnamed port>: In expression thisisabug:
<unnamed port>: Unbound variable: thisisabug
ABORT: (unbound-variable)
guile> (foo 10)
<unnamed port>: In expression thisisabug:
<unnamed port>: Stack overflow
ABORT: (stack-overflow)

The last message shows the previous unbound variable 'thisisabug'.
'foo' is just an example, this seems to happen for every function that
causes overflow.  It's not serious, but it sure looks misleading..

Neil Jerram sez:

It's something to do with the way that debug info frames cope with
stack overflow.

\f
bug 14 -- strange gc loop caused by trap misuse
reported-by: Neil Jerram <neil@ossau.uklinux.net> / 2002-02-03
fixed: not-yet

Neil Jerram sez:

Using the current unstable CVS Guile...

Running under gdb, type in the following:

(gdb) run -q
Starting program: /usr/local/bin/guile -q
guile> (trap-set! enter-frame-handler (lambda () 1))
(exit-frame-handler #f apply-frame-handler #f enter-frame-handler #<procedure #f ()> traps)
guile> (trap-enable 'enter-frame)

There is no response.  Wait a few seconds, and then C-c to send an
interrupt.  You'll find that the call stack shows a huge number of
recursive calls to scm_gc_mark (about 4000 per second waited on my
box).  (If you don't see scm_gc_mark immediately, you may have
interrupted too quickly: let it run for another second and then C-c
again.)

Here's as much of an explanation as I can offer...  The intended
effect of the two `trap' lines above is that the evaluator calls the
specified procedure every time it enters a new evaluation frame or is
about to perform an application.  However, the procedure above doesn't
accept the right number of arguments, so the attempt to call it gives
rise to a wrong-num-args error, which (I presume) jumps us out of that
level of the evaluator and is caught by the usual REPL machinery in
boot-9.scm.

Then, the next time that we need to GC, we hit this scm_gc_mark loop.
My guess is that something about the trap+error scenario has left data
or the stack in a state which exposes a bug in the GC.

\f
[BUGS ends here]