Custom Query (1030 matches)
Results (601 - 603 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #688 | invalid | ignore-errors doesn't | ||
| Description |
The following sequence of events produces a memory fault and a trip to a nonfunctioning debugger. (load "jpeg.lisp") ;supplied (jpeg::read-file "128.jpg") ;also supplied If you wrap the latter in ignore-errors, you still get the trip to the debugger. I tried this in the windows 32 bit 1.5 release as well as in the linux x86 64bit trunk (checked out as of this morning). |
|||
| #701 | fixed | kernel crash in 64 bit trunk build under 64 bit linux while gc'ing after creating large vector | ||
| Description |
I just checked all active tickets and didn't see any report like this. I also updated to the trunk and rebuilt to make sure this bug still exists there. (setq *print-array* nil) (setq foo (make-array 1000000000)) (length foo) (setq foo nil) 1 2 3 4 (gc) (the extra expressions/values were to get rid of pointers to the vector in *, and *) results in a sigsegv! |
|||
| #1184 | notabug | (read-from-string "#-genera" nil nil) should return nil, gets exception instead | ||
| Description |
I can understand why this happens, but if I supply an eof-error-p argument of nil and an eof-value of nil, I should just get nil, no? (At least that's how I interpret the hyperspec entry for read-from-string.) (I'm doing some processing of files line-by-line, and this line happened to come all by itself ahead of the definition of a function on the next few lines.) I tried this both in a shipped 1.9 and in a second 1.9 which had been updated via svn update and fully rebuilt. |
|||
