Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 4:39 PM, Carsten Mattner
<address@hidden> wrote:
> On Sat, Dec 17, 2011 at 9:32 AM, Eli Zaretskii <address@hidden> wrote:
>>> From: Andreas Schwab <address@hidden>
>>> Cc: Carsten Mattner <address@hidden>, address@hidden
>>> Date: Fri, 16 Dec 2011 22:24:26 +0100
>>>
>>> Eli Zaretskii <address@hidden> writes:
>>>
>>> > How come the x coordinate of an event could be passed to
>>> > ns_string_to_symbol as a string, no matter how it is type-cast??
>>>
>>> Because Fx_own_selection_internal put it there.
>>>
>>> (Get your barf bag ready!)
>>
>> Thanks for the heads-up, I needed that bag.
>>
>> So the question now is why that string comes out as NULL.  This
>> happens in this code in x-own-selection-internal:
>>
>>  pb =[NSPasteboard pasteboardWithName: symbol_to_nsstring (selection_name)];
>>
>> and the value of pb gets later put into the event's x member:
>>
>>  /* XXX An evil hack, but a necessary one I fear XXX */
>>  {
>>    struct input_event ev;
>>    ev.kind = SELECTION_REQUEST_EVENT;
>>    ev.modifiers = 0;
>>    ev.code = 0;
>>    *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
>>    *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
>>    ns_handle_selection_request (&ev);
>>  }
>>
>> Now, this part of the backtrace:
>>
>>  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>>  selection_value=39954401) at nsselect.m:425
>>          ev = {
>>            kind = SELECTION_REQUEST_EVENT,
>>            code = 0,
>>            part = 1771886,
>>            modifiers = 0,
>>            x = 0,
>>            y = -1396380776,
>>            timestamp = 1,
>>            padding = {0x4, 0x1a6ba22},
>>            frame_or_window = 27783754,
>>            arg = 27703842
>>          }
>>          pb = (id) 0x0
>>
>> indicates that pb comes out as NULL and gets put into ev.x as zero.
>> So the question is: what is selection_name, whose value is 27744162,
>> and which caused symbol_to_nsstring to return NULL?
>>
>> Carsten, if you still have the crashed session, please go to the stack
>> frame showing the call to Fx_own_selection_internal (in the above
>> case, this is frame #4), by typing "frame N" at the GDB prompt (where
>> N is the number of the frame), and then type these commands:
>>
>>  (gdb) p selection_name
>>  (gdb) xtype
>>
>> I expect the last command to say "Lisp_Symbol", in which case please
>> type
>>
>>  (gdb) xsymbol
>>
>> to show what symbol is that.
>>
>> If the crashed session is no longer available, make it crash as soon
>> as possible and then do the above.
>
> New session same #4 for that call
> (gdb) frame 4
> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
> selection_value=78814449) at nsselect.m:425
> 425         ns_handle_selection_request (&ev);
> Current language:  auto; currently objective-c
> (gdb) p selection_name
> $1 = 27744162
> (gdb) xtype
> Undefined command: "xtype".  Try "help".
> (gdb) xsymbol
> Undefined command: "xsymbol".  Try "help".
> (gdb)
>
> Could gdb be too old for xsymbol/xtype commands? Are those aliases?
> GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 
> 2011)
> Copyright 2004 Free Software Foundation, Inc.
>
> Apple prefers lldb and I have that ready and also could build
> lldb from svn trunk if there's a reason to do so.

This is with Xcode's lldb:
Process 486 stopped
* thread #1: tid = 0x1f07, 0x9adc5d50 libsystem_c.dylib`strlen + 16,
stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
    frame #0: 0x9adc5d50 libsystem_c.dylib`strlen + 16
(lldb) bt
* thread #1: tid = 0x1f07, 0x9adc5d50 libsystem_c.dylib`strlen + 16,
stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
    frame #0: 0x9adc5d50 libsystem_c.dylib`strlen + 16
    frame #1: 0x001e7601 Emacs`intern + 33 at lread.c:3707
    frame #2: 0x00283efb Emacs`ns_string_to_symbol + 459 at nsselect.m:86
    frame #3: 0x002847ab Emacs`ns_handle_selection_request + 75 at
nsselect.m:247
    frame #4: 0x00285202 Emacs`Fx_own_selection_internal + 370 at nsselect.m:425
    frame #5: 0x001b025b Emacs`Ffuncall + 1147 at eval.c:2989
    frame #6: 0x0020e3b1 Emacs`exec_byte_code + 3329 at bytecode.c:785
    frame #7: 0x001b0e01 Emacs`funcall_lambda + 1185 at eval.c:3217
    frame #8: 0x001b04a0 Emacs`Ffuncall + 1728 at eval.c:3035
    frame #9: 0x001af8e4 Emacs`call2 + 68 at eval.c:2770
    frame #10: 0x000f7a33 Emacs`command_loop_1 + 3779 at keyboard.c:1656
    frame #11: 0x001ac5d6 Emacs`internal_condition_case + 294 at eval.c:1499
    frame #12: 0x000f66cd Emacs`command_loop_2 + 61 at keyboard.c:1159
    frame #13: 0x001abebf Emacs`internal_catch + 223 at eval.c:1256
    frame #14: 0x000f664b Emacs`command_loop + 203 at keyboard.c:1138
    frame #15: 0x000f5b95 Emacs`recursive_edit_1 + 181 at keyboard.c:758
    frame #16: 0x000f5d86 Emacs`Frecursive_edit + 326 at keyboard.c:822
    frame #17: 0x000f3b6a Emacs`main + 6442 at emacs.c:1709
(lldb) frame 4
invalid command 'frame 4'
(lldb) frame
Available completions:
        info
        select
        variable
(lldb) frame select 4
frame #4: 0x00285202 Emacs`Fx_own_selection_internal + 370 at nsselect.m:425
   422      ev.code = 0;
   423      *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
   424      *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
-> 425      ns_handle_selection_request (&ev);
   426    }
   427    return selection_value;
   428  }
(lldb) p selection_name
(Lisp_Object) $0 = 27744162
(lldb)