Opened 12 years ago

Closed 11 years ago

#50 closed defect (fixed)

Exception when accessing text attributes in echo area buffers

Reported by: gb Owned by: gb
Priority: major Milestone: Cocoa IDE v1
Component: IDE Version: 1.1
Keywords: Cc:

Description

After some number of operations that write to/clear the echo area, I sometimes see an exception logged:

NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds

This seems to occur when #/attributesAtIndex:effectiveRange: is called on the textstorage object associated with an echo-area buffer; the hemlock buffer seems to be non-empty, but the parallel mutable attributed string has length 0.

I'm not sure what (hemlock stream operations ?) causes them to get out of sync.

Sometimes this seems to be recoverable; other times, it doesn't.

Change History (9)

comment:1 Changed 12 years ago by gb

  • Status changed from new to assigned

comment:2 Changed 12 years ago by gb

Things that I've seen consistently:

  1. The textstorage's "cache" string ("real" NSMutableAttributedString) is consistent with the Hemlock string. In several recent cases where I've seen this, both are empty.
  1. The call to attributesAtIndex:effectiveRange: that blows up is made from display code; the (foreign) backtrace shows that the NSLayoutManager is trying to determine text attributes at index 0 and that this was called from NSTextView's drawRect: method.

This suggests that the layout manager isn't picking up on the fact that CLEAR-ECHO-AREA - or something similar - has deleted the echo-area buffer's entire contents.

comment:3 Changed 12 years ago by gb

I think that this has to do with there being a pending #/beginEditing when a view is deactivated; there's then an outstanding #/beginEditing in effect when the view is reactivated, and the display/layout code gets confused.

A text view shouldn't really have any unprocessed editing changes when it becomes active or inactive.

comment:4 Changed 12 years ago by gb

I haven't seen this since implementing the change described in changeset:7046.

There's still some debugging code associated with that change; at one point, I thought that the problem had to do with view activation/deactivation occuring when #/beginEditing was in effect. I'm not sure that that was really the problem, but it's clear that the activation/deactivation needs to occur on the main thread.

Once that issue's resolved - and assuming that the symptom doesn't recur - it'd be possible to close this bug.

comment:5 Changed 12 years ago by gb

It seems to occur much less frequently than it had, but I got the DBG trap associated with it a little earlier today.

As generally seems to be the case when this happens, there was a pending #/beginEditing on the echo-area textstorage when something tried to access character attributes.

comment:6 Changed 12 years ago by gb

I've been trying to find the cause of this (out-of-bounds error in #/attributesAtIndex:effectiveRange: on the hemlock-text-storage associated with an echo area buffer) by finding the command thread for the window and PROCESS-INTERRUPTing it with CCL::DBG (enter the kernel debugger). It seems that HI::CLEAR-ECHO-AREA is always on the stack.

HI::CLEAR-ECHO-AREA calls HI::DOCUMENT-SET-POINT-POSITION, which can cause redisplay. It should presumably do this only if the document's textstorage's change count is 0, but this isn't guaranteed to be the case (we might be modifying the echo area buffer when we decide to clear it; we should only update the display code's notion of where the selection is when we're officially done making changes to the buffer.)

I think that the debugging technique used here (forcing a breakpoint in a window's command thread when the event thread misbehaves) would often catch this sort of thing, because the hemlock command thread will rarely have left the scene of the crime (it'll be waiting for a #/performSelectorOnMainThread:withObject:waitUntilDone: call to return.)

comment:7 Changed 12 years ago by gb

I've seen this less often than I'd been seeing it, but I've been running on a single-processor system for the last several days.

comment:8 Changed 12 years ago by gb

One way to provoke this (that doesn't seem to be timing-sensitive and seems entirely reproducible):

  1. Open a new buffer; enter "abc", a newline, a space, and "def".
  1. Position the cursor before the space on the second line, then do:
    m-x Delete Indentation
    
  2. Blammo.

This seems to have to do with how the text system is notified of deletions.

comment:9 Changed 11 years ago by jaj

  • Milestone set to Cocoa IDE v1
  • Resolution set to fixed
  • Status changed from assigned to closed

I'm closing this bug. I haven't seen this in a long time, and I can't reproduce the bug using the instructions in the comment from 9/30/07. I anyone sees this bug, or especially if someone comes up with a reproducable test case, then we can reopen the bug.

Note: See TracTickets for help on using tickets.