Am 08.03.2010 07:22, schrieb Richard Frith-Macdonald: > > 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.
I agree with you that we should not just fix the problem on GSMutableArray, but need to find out, why behaviours aren't working with old runtimes. I tried to run the test suite to see whether it shows any obvious problems. It turns out the test suite is completely broken for me :-( I look at the first issue and there it should just be testWriteBasicType_ushort instead of testWriteBasicType_short. Probably most of the other issues are as simple as that. I will work my way through the test suite, and report the remaining problems. Fred --- Running tests in base --- base/coding/basictypes.m: FAIL: base/coding/basictypes.m base/coding/decoding.m: FAIL: base/coding/decoding.m base/Functions/NSGeometry1.m: FAIL: near identical points are equal FAIL: near identical sizes are equal FAIL: near identical rects are equal base/Functions/runtime.m: FAIL: base/Functions/runtime.m base/KVC/mutable.m: ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) ofObject:<Lists: 0x6856c0> context:(null) base/NSException/basic.m: FAIL: raises exception in description FAIL: working callStackSymbols : Uncaught exception NSGenericException, reason: Terminate FAIL: base/NSException/basic.m base/NSKeyedArchiver/basic.m: FAIL: raises exception in description FAIL: raises exception in description base/NSLock/doubleLocking.m: FAIL: Recursive lock with NSLock deadlocks ... this is not a real test, just a reminder that recursively locking should deadlock the thread after printing a diagnostic message FAIL: Recursive lock with NSConditionLock deadlocks ... this is not a real test, just a reminder that recursively locking should deadlock the thread after printing a diagnostic message base/NSMutableArray/basic.m: FAIL: base/NSMutableArray/basic.m base/NSStream/socket.m: FAIL: read www.google.com https 1 255 COMPLETED 7 context 15 FAIL 7 ofObject 5129 PASS _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev