Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#688 closed defect (invalid)

ignore-errors doesn't

Reported by: lispwizard Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:


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).

Attachments (1)

jpeg.lisp (108.3 KB) - added by lispwizard 11 years ago.
Slightly modified Jpeg reading/writing code from Chris Vogt

Download all attachments as: .zip

Change History (4)

Changed 11 years ago by lispwizard

Slightly modified Jpeg reading/writing code from Chris Vogt

comment:1 Changed 11 years ago by lispwizard

Trac wouldn't let me upload the image (it was 1.1 megabytes).

I can email it to anyone looking into this bug, just contact me (kalman.reti@…).

comment:2 Changed 11 years ago by gb

  • Resolution set to invalid
  • Status changed from new to closed

Memory faults - if there seems to be some possiblity of continuing after they're detected - cause STORAGE-CONDITIONs (not ERRORs) to be signaled, so it's not surprising that IGNORE-ERRORS doesn't ignore them.

? (defun foo (x)
  (declare (optimize (speed 3) (safety 0)))
  (cdr x))
? (foo 17)
> Error: Fault during read of memory address #x ...

? (handler-case (progn (foo 17)) (serious-condition (condition) (values nil condition)))

So, the condition system seems to work and the ticket's subject is invalid. I suppose that the real problem is that you get memory faults while using the attached code to load a jpeg file, either due to a bug in CCL or a bug in that code itself (which seems to be compiled with aggressive optimization by default, which means that errors in that code may be undetected and may lead to undefined behavior - like memory faults.) A first step would seem to be to change the default optimization setting (resetting the optimize quantities to 1 is probably good enough to catch most problems). If you get errors instead of faults ... well, what that means depends on what the errors are, but it may be easier to diagnose the problem rather than what might be a symptom of the problem.

In the simple case above - trying to take the CDR of 17 without checking that CDR's arg was LISTP - it happens to be fairly easy to recover from the situation (it's no worse than a lisp-level error in reasonably safe code.) It's possible for buggy code to scribble over memory for a while before that scribbling actually causes a fault, so it's by no means guaranteed that the lisp is in a functional state when an unexpected memory fault occurs.

If a memory fault occurs while foreign (C) code is executing, there's generally no meaningful way to recover and you wind up in a kernel debugger (described in some detail in the manual.) That debugger's sometimes a little helpful (it can sort of print lisp values readably and do a few things that can get one oriented when trying to debug lisp code, but it's almost completely unable to debug foreign code. (Fortunately, most systems offer debuggers that're very good at that.)

It's not clear whether the "non functioning debugger" you referred to was a lisp break loop or the kernel debugger; if a lisp break loop isn't functional, then the memory fault was likely just a small part of a larger memory corruption scenario.

In any case: STORAGE-CONDITIONs aren't errors. Please try toning down optimization in jpeg.lisp and see if that helps to identify the problem, and if the problem seems to have something to do with CCL please open another ticket.

comment:3 Changed 11 years ago by lispwizard

The "non-functional debugger" was a lisp break loop; its non-functionality had to do with the fact that no commands worked, i.e. :b or :f <n> would give the same memory error, so it was hard to figure out what was going on.

Note: See TracTickets for help on using tickets.