Re: Problem with NSTextView

[David Chisnall]

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
>>> 
>>> 
>>> 
>>> -- Sent from my Difference Engine
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my IBM 1620