Re: Gorm brokeness

[Richard Frith-Macdonald]

On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote:

> 
> On 7 Mar 2010, at 19:10, Fred Kiefer wrote:
> 
>> Just to keep you informed on my current finding. I could follow a mouse
>> down event that should start a drag into the method [XGDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] there the call
>> to mimeTypeForPasteboardType() seems to fail, when doing manual calls in
>> gdb I get
>> 
>> (gdb) po pboard
>> <NSPasteboard: 0x11b68e0>
>> (gdb) p [pboard types]
>> $14 = (class NSArray *) 0x109a610
>> (gdb) po [pboard types]
>> <NSDistantObject fee2c0>
>> (gdb) p [[pboard types] count]
>> $15 = (void *(*)()) 0x7fffef701000
>> (gdb) p (int)[[pboard types] count]
>> $16 = -277884928
>> (gdb) p (long)[[pboard types] count]
>> $17 = 140737210454016
>> 
>> Now this may not the the root of the problem, but it looks strange to
>> me. But why wont the function mimeTypeForPasteboardType return?
>> After adding a breakpoint in [NSException raise] I get:
>> 
>> (gdb) bt
>> #0  -[NSException raise] (self=0x1056940, _cmd=0x7ffff6c03ab0) at
>> NSException.m:899
>> #1  0x00007ffff6818300 in -[NSConnection(GNUstepExtensions)
>> forwardInvocation:forProxy:] (self=0xfba420,
>>   _cmd=0x7ffff6c105c0, inv=0x1062840, object=0x11a81a0) at
>> NSConnection.m:2090
>> #2  0x00007ffff6928507 in GSFFIInvocationCallback (cif=<value optimized
>> out>, retp=0x7fffffffc670,
>>   args=<value optimized out>, user=<value optimized out>) at
>> GSFFIInvocation.m:636
>> #3  0x00007ffff47d9729 in ffi_closure_unix64_inner (closure=<value
>> optimized out>,
>>   rvalue=<value optimized out>, reg_args=0x7ffff5d04d3a,
>> argp=0x7fffffffc690 "@#�")
>>   at src/x86/ffi64.c:620
>> #4  0x00007ffff47da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228
>> #5  0x00007ffff31f799a in mimeTypeForPasteboardType (types=<value
>> optimized out>,
>>   zone=<value optimized out>, xDisplay=<value optimized out>) at
>> XGDragView.m:140
>> #6  -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:]
>> (types=<value optimized out>,
>>   zone=<value optimized out>, xDisplay=<value optimized out>) at
>> XGDragView.m:217
>> #7  0x00007ffff7b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460,
>> _cmd=<value optimized out>,
>>   theEvent=0xf8cd00) at GormPalettesManager.m:236
>> #8  0x00007ffff6ff7393 in -[NSWindow sendEvent:] (self=0xc32340,
>> _cmd=<value optimized out>,
>>   theEvent=0xf8cd00) at NSWindow.m:3666
>> #9  0x00007ffff6e94af4 in -[NSApplication run] (self=<value optimized
>> out>, _cmd=<value optimized out>)
>>   at NSApplication.m:1530
>> #10 0x00007ffff6e7612e in NSApplicationMain (argc=<value optimized out>,
>> argv=<value optimized out>)
>>   at Functions.m:74
>> #11 0x00007ffff5ca5a7d in __libc_start_main () from /lib64/libc.so.6
>> #12 0x0000000000401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113
>> 
>> (gdb) po self
>> <NSException: 0x1056940> NAME:NSInvalidArgumentException REASON:subclass
>> GSMutableArray(instance) should override count
>> 
>> 
>> Looks like this method go lost in recent rewrites of base :-)
> 
> Absolutely not.
> It's 'inherited' from GSArray using behavors, so should not be implemented in 
> GSMutableArray.
> Also, many of the regression tests and lots of other code would clearly have 
> failed horribly if mutable arrays didn't work.
> So how can you get this exception?  Presumably some runtime issue.  I rewrote 
> the behavior code to use the new runtime API rather than the old one, and 
> while it's clearly working fine most of the time, perhaps there's something 
> finding a bug in this case?
> 
>> I will fix this and also change all the parameters in GSArray.m to
>> NSUInteger that are now changed in the super class NSArray.
> 
> Now this looks also like a possible cause of the problem (especially if the 
> people experiencing this problem are using 64bit systems and it's not showing 
> up on any 32bit systems).
> 
> I'll remove the -count method again, and we can see whether the change to 
> using NSUInteger fixed the issue.
> 
> I''ll also look see if I can spot any possible problem in the mechanism for 
> inheriting -count.

None spotted so far.  I have improved the debug though...

If you set the GNUSTEP_BEHAVIOR_DEBUG environment variable to YES,  you will 
get all the inherited behaviors logged to stderr and can see if there is 
anything going wrong there.  It will report each method added or replaced in 
the class (as well as methods skipped because the class already has an 
implementation).

 So if the NSUinteger changes did not fix things, and there is an issue with 
'inheriting' the -count method, this should give us a clue about where to look.