Pasting into mini-buffer doesn't work

[jaj]

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.

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

[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

[jaj]

Easily reproducible in r11688.

[gb]

see also ticket:424.

[rme]

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