discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with NSTextView


From: David Chisnall
Subject: Re: Problem with NSTextView
Date: Sun, 29 Jan 2012 20:50:19 +0000

This sounds correct.  I believe that sel_registerName() may return a typed 
selector if there is only one selector registered for a specific type - this 
may happen if it is called when the runtime has only loaded the class with the 
wrong type encoding, and not the one with the correct one.  I should probably 
make sure that it always returns untyped selectors.

David

On 29 Jan 2012, at 20:41, Fred Kiefer wrote:

> When decoding actions we call, NSSelectorFromString() and this internally 
> uses sel_registerName(). According to your mail this is the right way to do 
> it even for clang.
> You talk about a wrong way to generate selectors, could you explain what that 
> would be?
> 
> Fred
> 
> On 29.01.2012 12:54, David Chisnall wrote:
>> The runtime won't generate this warning if the selector has no type
>> information (selectors returned by @selector() are untyped, for
>> example).  If it comes from nib loading, then it sounds like we're
>> creating the selector the wrong way.  We should be calling
>> sel_registerName(), which will give an untyped selector.  If the nib
>> is storing the type information, then I'd expect it to be an
>> IBAction, but the error is appearing because it is NOT an
>> IBAction...
>> 
>> David
>> 
>> P.S. These messages are not shown in release builds of the runtime,
>> but the extra cost of the double lookup for incorrect type signatures
>> is still present.
>> 
>> On 28 Jan 2012, at 21:29, Eric Wasylishen wrote:
>> 
>>> Hi, Based on Sebastain's bactrace, I think it's a spurious warning:
>>> the method isn't actually being called with an incorrect signature,
>>> the menu update code is just calling class_respondsToSelector() to
>>> check if an object responds to the selector "copy:". The selector
>>> being passed probably comes from nib loading, so any type info is
>>> random.
>>> 
>>> Eric
>>> 
>>>> 
>>>> #0  fprintf (fp=0x2d086310, fmt=0x2ccc6c6f "Calling [%s %c%s]
>>>> with incorrect signature.  Method has %s, selector has %s\n") at
>>>> /usr/src/lib/libc/stdio/fprintf.c:44 #1  0x0ccdb448 in
>>>> objc_selector_type_mismatch (cls=0xcfbd5274, selector=0xcfbd5274,
>>>> result=0xcfbd5274) at sendmsg2.c:37 #2  0x0ccdc22c in
>>>> objc_get_slot (cls=Unhandled dwarf expression opcode 0x0 ) at
>>>> sendmsg2.c:307 #3  0x0ccdc26f in class_respondsToSelector
>>>> (cls=dwarf2_read_address: Corrupted DWARF expression. ) at
>>>> sendmsg2.c:322 #4  0x0a102e78 in -[NSObject respondsToSelector:]
>>>> (self=dwarf2_read_address: Corrupted DWARF expression. ) at
>>>> NSObject.m:2096 #5  0x09977ff1 in -[NSApplication(Private)
>>>> _targetForAction:keyWindow:mainWindow:] (self=0x8a57a984,
>>>> _cmd=0x29805088, aSelector=0x8be49550, keyWindow=0x7fbfe304,
>>>> mainWindow=0x7fbfe304) at NSApplication.m:3897 #6  0x0996dae1 in
>>>> -[NSApplication targetForAction:] (self=0x8a57a984,
>>>> _cmd=0x29804d08, aSelector=0x8be49550) at NSApplication.m:2290 #7
>>>> 0x0996d98c in -[NSApplication targetForAction:to:from:]
>>>> (self=0x8a57a984, _cmd=0x29837640, theAction=0x8be49550,
>>>> theTarget=0x0, sender=0x84fdf904) at NSApplication.m:2275 #8
>>>> 0x09b2891c in -[NSMenu update] (self=0x80ffd844, _cmd=0x29837190)
>>>> at NSMenu.m:1151 #9  0x09b287f2 in -[NSMenu update]
>>>> (self=0x81921144, _cmd=0x29805228) at NSMenu.m:1146 #10
>>>> 0x09969901 in -[NSApplication run] (self=0x8a57a984,
>>>> _cmd=0x297fe900) at NSApplication.m:1570 #11 0x0992466d in
>>>> NSApplicationMain (argc=1, argv=0xcfbd5c14) at Functions.m:91 #12
>>>> 0x1c005ec7 in ___start () #13 0x1c005e42 in _start ()
>>>> 
>>>> 
>>>> Sebastian
>>>> 
>>>>> 
>>>>> On 28 Jan 2012, at 13:17, Sebastian Reitenbach wrote:
>>>>> 
>>>>>> Method has v12@0:4@8, selector has @12@0:4@8
>>>>> 
>>>>> This looks potentially dangerous.  The caller is expecting the
>>>>> method to return an object, but the method is a standard
>>>>> IBAction (i.e. returning void).  If the caller does anything
>>>>> with the return value, then it will likely crash...
>>>>> 
>>>>> David
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my brain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]