Opened 12 years ago

Closed 12 years ago

#139 closed defect (fixed)

Fatal exception while printing backtrace

Reported by: gz Owned by: gb
Priority: major Milestone:
Component: IDE Version:
Keywords: Cc:

Description

As of r7528 there is a bug in incremental search, which can usually be triggered by doing wrapping incremental search, back and forward a few times and then exiting it and perhaps clicking the mouse. This here is NOT a bug report about that bug. But when you do hit that bug, you get an error about NIL not being a structure, and the lisp craps out trying to show the backtrace.

I've had it happen one of two ways: sometimes it gets an exception and enters the kernel debugger. Other times it still seems to get an exception, but somehow manages to handle it and prints some backtraces about the error within the error. In the second case, you can actually just kill the window that caused the problem, and continue with the same lisp. In the first case, the lisp is hosed.

I've attached terminal output for both cases.

Attachments (2)

exception-with-debugger.txt (16.6 KB) - added by gz 12 years ago.
backtrace for the fatal case
exception-without-debugger.txt (7.7 KB) - added by gz 12 years ago.
backtrace for the non-fatal case

Download all attachments as: .zip

Change History (5)

Changed 12 years ago by gz

backtrace for the fatal case

Changed 12 years ago by gz

backtrace for the non-fatal case

comment:1 Changed 12 years ago by gb

The (primary) error occurs in the event thread. (CCL::MARK-ABSOLUTE-POSITION is only called by one function in cocoa-ide/hemlock/src: something used to print font-marks, which may or may not even be used.)

CCL::MARK-ABSOLUTE-POSITION assumes that its argument is a MARK and that several of its fields are structures which may refer to other structures (LINEs, BUFFERs, etc.) It'll certainly crap out if any of these assumptions is false, as may attempts to print the MARK or its components.

To try to expedite debugging this, we could try making the (optimistic) backtrace that's written to standard output when an exception occurs in the event thread (a) try to skip printing frame detail - yes, we'd want it but skipping it would at least give us an idea of what code path is involved and/or (b) print it in a way that will shut up and unwind the ObjC exception stack properly and resume event-processing ASAP if an error occurs.

comment:2 Changed 12 years ago by gz

Just to clarify -- the isearch bug is just a fairly reliable way to reproduce the actual bug I am reporting here, which is that printing the backtrace crashes the lisp. (FWIW, Jeremy already fixed the isearch bug, so emergency help is not needed)

comment:3 Changed 12 years ago by gz

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

This was fixed by changeset:7593 and changeset:7594.

Note: See TracTickets for help on using tickets.