gnustep-dev
[Top][All Lists]
Advanced

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

Re: Gorm brokeness


From: Fred Kiefer
Subject: Re: Gorm brokeness
Date: Mon, 08 Mar 2010 11:33:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0

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





reply via email to

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