Opened 14 years ago

Closed 14 years ago

#135 closed defect (fixed)

cmd-click blows away IDE

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


This was reported on info-mcl.

Entering cmd-click makes the standalone IDE quit immediately.

Console shows: [15014] OpenMCL kernel debugger: Unhandled exception 11 at 0xfffeff18, context->regs at #xbfffe1e8 Read operation to unmapped address 0x21

In foreign code at address 0xfffeff18

Attachments (1)

patch.text (685 bytes) - added by rme 14 years ago.
patch to cocoa-editor.lisp

Download all attachments as: .zip

Change History (9)

comment:1 Changed 14 years ago by gb

  • Status changed from new to assigned

I'm still not sure why it's crashing, but note that the default behavior of cmd-click involves trying to open URLs embedded in the text.

comment:2 Changed 14 years ago by rme

FWIW, this appears to be PPC-specific.

Command-clicking is used in text views to make non-contiguous selections. This works on my x86-64 system running Leopard 9A559.

(Note that cmd-E will evaluate all the non-contiguous regions.)

Changed 14 years ago by rme

patch to cocoa-editor.lisp

comment:3 Changed 14 years ago by rme

Try the attached patch.

comment:4 Changed 14 years ago by gz

The patch fixes it on PPC/Tiger. It doesn't crash, and makes non-contiguous selections.

comment:5 Changed 14 years ago by gb

It does look like there's a race condition in the unpatched code. What seems to happen is that some flavors of cmd-click wait for a mouse-up or mouse drag; while they're waiting, the hemlock thread wakes up, processes the #k"leftmouse" (which is a no-op), then says "update the selection" to the event thread. All kinds of chaos happens, and then the mouse-up/drag happens.

When a mousedown is being processed by -[NSTextView mousedown:], it makes several calls to #/selectionRangeForProposedRange:granularity:, which mucks around in the buffer and may set the selection to something other than what was "proposed" if there are parens nearby. This really shouldn't be running when an editor command (even a trivial one) is also mucking around in the buffer on another thread.

Not saying "here, run an editor command while I call-next-method" might tempt fate a bit less, but I think that the real problem's a bit deeper.

comment:6 Changed 14 years ago by rme

I could be missing something, but it's not clear to me why #/mouseDown: is being overridden in the first place.

I removed it, and it appeared to have no immediate adverse effects, and it had the positive effect of not crashing on cmd-click, and also corrected the unusual selection behavior mentioned in ticket:119.

Isn't Hemlock's notion of the selection already going to be correct after any mouse activity already, thanks to #/setSelectedRange:affinity:stillSelecting:?

comment:7 Changed 14 years ago by gb

#/mouseDown is overridden so that we can post an event to hemlock; that event is used to terminate isearch.

comment:8 Changed 14 years ago by gz

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

I checked in Matt's patch, it works, bug gone.

Note: See TracTickets for help on using tickets.