#58: UTF-16 buffering problem
---------------------+------------------------------------------------------
Reporter: rtoy | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Unicode | Version: 2012-04
Keywords: |
---------------------+------------------------------------------------------
The following code should not cause errors:
{{{
(with-open-file (s "test.txt" :direction :output :external-format :utf-16)
(dotimes (i 300)
(write-char (code-char i) s)))
(with-open-file (s "test.txt" :direction :input :external-format :utf-16)
(dotimes (i 300)
(let ((ch (read-char s nil nil)))
(unless (= i (char-code ch))
(format t "Error at ~D: ~S, ~4X~%" i ch (char-code ch))))))
}}}
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/58>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#55: blocked signals
--------------------------------+-------------------------------------------
Reporter: heller | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 20c
Keywords: signals interrupts |
--------------------------------+-------------------------------------------
I think there is a problem related to blocked signals and garbage
collection:
1. Start {{{cmucl -noinit -eval '(loop (ext:gc :full t))'}}} in a terminal
and let it run.
2. Under Linux, {{{cat /proc/<pid>/status}}} shows that !SigBlk is 0
i.e. no signals are blocked.
3. Interrupt the loop with C-c (SIGINT) and wait for the debugger.
4. !SigBlk is still 0.
5. Type c to continue the loop.
6. !SigBlk is now 000000001fc90000
That's a bug, right? It should again be zero.
The problem doesn't occur if the loop is empty, so I figure this
has something to do with GC.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/55>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#57: Heap overflow checking fails on sparc
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 2012-01
Keywords: |
--------------------+-------------------------------------------------------
{{{
cmulisp -dynamic-space-size 32
* (defvar *1* (make-list 10000000))
*A2 gc_alloc_new_region failed, nbytes=8.
CMUCL has run out of dynamic heap space (32 MB).
You can control heap size with the -dynamic-space-size commandline
option.
segv_handler: Real protection violation: 400, PC = 1bbcc
*A2 gc_alloc_new_region failed, nbytes=8.
CMUCL has run out of dynamic heap space (32 MB).
You can control heap size with the -dynamic-space-size commandline
option.
Segmentation Fault (core dumped)
}}}
I'm pretty sure this used to work on sparc. The fault address of
{{{0x1bbcc}}} is in {{{build_fake_control_stack_frame}}}.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/57>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#54: Testing ticket mailing list
-------------------------+--------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: closed
Priority: major | Milestone:
Component: Core | Version: 2012-01
Resolution: worksforme | Keywords:
-------------------------+--------------------------------------------------
Comment(by rtoy):
For the record, [http://trac.edgewall.org/wiki/TracNotification trac
notification] has to be configured with {{{smtp_enabled}}} set to true.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/54#comment:3>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.
#44: error with MAKE-METHOD-LAMBDA or method combinations
--------------------+-------------------------------------------------------
Reporter: gpfeil | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: Core | Version: 20b
Keywords: |
--------------------+-------------------------------------------------------
In a project I have on GitHub, Quid Pro Quo, many of my tests fail with an
error, “Invalid number of arguments: 1”.
The top of the stack:
0: ("LAMBDA (.METHOD-ARGS. .NEXT-METHODS.)" 1 (NIL #<QUID-PRO-QUO-
TEST::TEST-2 {494C20E5}>) #<unused-arg>)[:EXTERNAL]
Locals:
#:G11 = 1
#:G12 = (NIL #<QUID-PRO-QUO-TEST::TEST-2 {494C20E5}>)
leads me to believe that it has something to do with MAKE-METHOD-LAMBDA.
There are more details in an issue on that project:
https://github.com/sellout/quid-pro-quo/issues/2
I'm not yet at the point of thinking this is a CMUCL bug, as I know I am
dealing with areas of Lisp that are relatively fuzzy and there are a
number of times I've had it work on one compiler but not another.
Currently, SBCL, Clozure CL, and Allegro pass all but one test (which is
expected to fail), so I'm slowly building up my confidence. But CMUCL and
LispWorks are still eluding me.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/44>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.