Custom Query (1030 matches)
Results (757 - 759 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #978 | fixed | native-translated-namestring merges with *default-pathname-defaults* | ||
| Description |
The manual doesn't say it does, but native-translated-namestring merges its argument with *default-pathname-defaults*, which does nothing when the default value of #p"" is used, but can yield interesting results in other cases. This behavior is not mentioned in the manual: http://ccl.clozure.com/manual/chapter4.6.html Personally, I'd consider that a bug, for merging is not what I'd expect from this function. However, maybe you have a different idea and this behavior is what you desire - in which case I consider that a bug in the documentation, for that is very surprising (to me at least). My workaround is to bind *default-pathname-defaults* to #p"" around my call to native-translated-namestring. |
|||
| #979 | worksforme | Trac sometimes logs users out inexplicably | ||
| Description |
I just spent half an hour writing a detailed bug report. When I clicked "preview", the website told me I didn't have write permissions because I wasn't logged in. I had logged in earlier, but my login somehow timed out because of dubious "security" settings. Now the form is reset and my bug report is lost. I'm pissed. Can you fix your interface so that it (1) won't log me out so fast, and (2) won't drop my painfully written bug report. |
|||
| #980 | fixed | Race condition(?) during image dump | ||
| Description |
Once in a while, dumping an image using CCL yields a dysfunctional executable that crashes with low-level errors when used. My guess, coherent with the symptoms, is that there is a race condition that causes threads to not be cleaned up properly before the image is dumped, and the runtime is subsequently confused when it resumes from such an messed up state. If correct, then a solution would then better to synchronize with threads being terminated, and/or to teach the runtime to clean up the mess when re-starting. I've observed the symptom in the past, using CCL 1.7 while compiling QRes and probably earlier versions of CCL. But there was too much state to be reproducible, what more involving proprietary software. Today, I reproduced the bug with CCL 1.8, during the early steps of an XCVB build, therefore with very little state if at all, while testing XCVB itself, all of it free software. Attached will be the log of all XCVB testing (27MB uncompressed, .5MB bzip2'ed) - search for TYPE-ERROR near the end, and the resulting dysfunctional image (27MB uncompressed, 5MB bzip2'ed). Ubuntu Lucid on amd64 linux-image-2.6.32-41-generic libc6-2.11.1-0ubuntu7.10 Clozure Common Lisp Version 1.8-r15359M (LinuxX8664) XCVB 0.579-5-gb4086ee The (reformatted) commands run to build the dysfunctional image were: ccl --no-init --quiet --batch --eval \
"(let ((x
(multiple-value-bind (output warningp failurep)
(let ((*default-pathname-defaults*
(truename *default-pathname-defaults*)))
(handler-bind (((or #+sbcl sb-c::simple-compiler-note
#+ecl c::compiler-note
#+ecl c::compiler-debug-note
#+ecl c::compiler-warning)
#'muffle-warning))
(compile-file \"/tmp/tunes/xcvb-release/xcvb/driver.lisp\"
:verbose nil :print nil :output-file
(merge-pathnames
#P\"/tmp/tunes/xcvb-test/obj/xcvb/driver__temp.lx64fsl\"))))
(if (or (not output) #-(or clisp ecl) warningp #-clisp failurep)
1 0))))
(finish-output *standard-output*) (finish-output *error-output*)
(ccl:quit x))"
mv /tmp/tunes/xcvb-test/obj/xcvb/driver__temp.lx64fsl \
/tmp/tunes/xcvb-test/obj/xcvb/driver.lx64fsl
xcvb make-manifest --output \
/tmp/tunes/xcvb-test/obj//___initial.manifest --spec \
"((:command (:load-file (:fasl \"/xcvb/driver\"))
:pathname \"/tmp/tunes/xcvb-test/obj//xcvb/driver.lx64fsl\"))"
ccl --no-init --quiet --batch --load \
/tmp/tunes/xcvb-test/obj//xcvb/driver.lx64fsl --eval \
"(xcvb-driver::run
(:create-image (#P\"/tmp/tunes/xcvb-test/obj/___temp.image\"
:output-name \"_\" )
(:initialize-manifest
\"/tmp/tunes/xcvb-test/obj//___initial.manifest\")))"
mv /tmp/tunes/xcvb-test/obj/___temp.image \
/tmp/tunes/xcvb-test/obj/_.image
The next command, that triggered the error, was: /tmp/tunes/xcvb-test/obj/_.image --no-init --quiet --batch --eval \
"(xcvb-driver::run
(:compile-lisp
(\"/tmp/tunes/xcvb-release/xcvb/examples/example-1/package.lisp\"
#P\"/tmp/tunes/xcvb-test/obj/xcvb/example-1/package__temp.lx64fsl\")))"
The (reformatted) error output before the process exited with error code 255 was: > Error of type TYPE-ERROR: value 0 is not of the expected type
(OR CCL::NAMED-CTYPE CCL::NUMERIC-CTYPE CCL::ARRAY-CTYPE CCL::MEMBER-CTYPE
CCL::CLASS-CTYPE CCL::UNION-CTYPE CCL::INTERSECTION-CTYPE CCL::CONS-CTYPE
CCL::UNKNOWN-CTYPE CCL::NEGATION-CTYPE CCL::HAIRY-CTYPE CCL::FUNCTION-CTYPE).
> While executing: CCL::%%TYPEP, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
> Error of type CCL::INVALID-MEMORY-ACCESS: Fault during read of memory address #x3
> While executing: CCL::CELL-CSUBTYPEP-2, in process listener(1).
Note that:
Xref: ITA bug 106299 |
|||
