Ticket #258 (closed defect: fixed)

Opened 7 years ago

Last modified 5 years ago

Pasting into mini-buffer doesn't work

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

Description

This is easily reproducible. In any editor or listener, do a m-x grep, which asks for a pattern in the mini-buffer. Now do a command-v to paste, and it crashes into the kernel debugger.

Change History

comment:1 Changed 7 years ago by gb

It enters the kernel debugger because of the call to ccl::dbg in the #/attributesAtIndex:effectiveRange: method on hemlock-text-storage.

The dbg call was an attempt to understand what was causing ticket:50; this seems to provoke the same sort of behavior that that bug did, perhaps for different reasons.

comment:2 Changed 7 years ago by gz

More analysis from openmcl-devel discussion:

At 6/9/2008 01:40 AM, Gary Byers wrote:
... provoked via "M-x" (to get the "Extended Command: " prompt in the echo area), pasting into the echo area logs a message like:

  2008-06-08 23:22:32.642 dx86cl64[1214:613] Bounds error - Attributes at index: 18  edit-count: 2 mirror: Extended Command: {
[... lots of info about the attributed string ...]
)

and a backtrace shows:

(#x00000000004421E8) #x00003000401151AC : #<Function %PASCAL-FUNCTIONS% #x000030004011501F> + 397
(#x00000000004422A8) #x00003000413B49C4 : #<Anonymous Function #x00003000413B479F> + 549
(#x00000000004422D8) #x0000300040E1999C : #<Function %CALL-NEXT-OBJC-METHOD #x0000300040E1964F> + 845
(#x0000000000442338) #x000030004140EE9C : #<Function -[LispApplication sendEvent:] #x000030004140EA1F> + 1149
(#x00000000004423B0) #x00003000401151AC : #<Function %PASCAL-FUNCTIONS% #x000030004011501F> + 397
(#x0000000000442470) #x00003000412DBE9C : #<Anonymous Function #x00003000412DBDCF> + 205
(#x0000000000442490) #x0000300040E16D5C : #<Function (:INTERNAL SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (OBJC-DISPATCH-FUNCTION T))) #x0000300040E16B5F> + 509
(#x00000000004424D8) #x00003000414AB074 : #<Function EVENT-LOOP #x00003000414AAEEF> + 389
(#x0000000000442550) #x00003000416BB2DC : #<Function (:INTERNAL PARSE-FOR-SOMETHING) #x00003000416BB03F> + 669
(#x0000000000442600) #x0000300041B12CCC : #<Function INVOKE-MODIFYING-BUFFER-STORAGE #x0000300041B12B0F> + 445
(#x0000000000442660) #x00003000416BB734 : #<Function (:INTERNAL PARSE-FOR-SOMETHING) #x00003000416BB45F> + 725
(#x0000000000442700) #x0000300041B12CCC : #<Function INVOKE-MODIFYING-BUFFER-STORAGE #x0000300041B12B0F> + 445
(#x0000000000442760) #x00003000416BBC54 : #<Function PARSE-FOR-SOMETHING #x00003000416BB9CF> + 645
(#x0000000000442828) #x00003000416D97F4 : #<Function EXTENDED-COMMAND-COMMAND #x00003000416D974F> + 165
(#x0000000000442840) #x000030004159A7AC : #<Method-Function EXECUTE-HEMLOCK-KEY (HEMLOCK-VIEW T) #x000030004159A40F> + 925
(#x0000000000442908) #x000030004159839C : #<Function (:INTERNAL (HANDLE-HEMLOCK-EVENT (HEMLOCK-VIEW T))) #x000030004159816F> + 557

So, we're in sort of a recursive event loop processing key events in the echo area, and may not be aware of the fact that other things ("paste" and other menu commands) are modifying the echo area buffer.

On Sun, 8 Jun 2008, Rich Sutton wrote:

this seems to be a little bug, and i have not seen it previously reported:

in clozure cl 1.2 rc1, if you invoke query-replace and then try to use paste (e.g., from the edit menu) to provide the first string, then clozure cl crashes.

rich

comment:3 Changed 6 years ago by jaj

  • Milestone set to Cocoa IDE v1

Easily reproducible in r11688.

comment:4 Changed 6 years ago by gb

see also ticket:424.

comment:5 Changed 6 years ago by jaj

  • Owner changed from gz to jaj
  • Summary changed from Pasting into mini-buffer crashes to Pasting into mini-buffer doesn't work

comment:6 Changed 6 years ago by jaj

  • Status changed from new to assigned

comment:7 Changed 6 years ago by gz

  • Owner jaj deleted
  • Status changed from assigned to new

comment:8 Changed 5 years ago by rme

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

Seems to be fixed now; the fix for ticket:360 probably fixed this too.

Note: See TracTickets for help on using tickets.