gnustep-dev
[Top][All Lists]
Advanced

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

Re: Gorm brokeness


From: Matt Rice
Subject: Re: Gorm brokeness
Date: Mon, 8 Mar 2010 01:54:38 -0800

On Mon, Mar 8, 2010 at 1:30 AM, Richard Frith-Macdonald
<address@hidden> wrote:
>
> 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.
>

It doesn't seem related, but i've also been seeing some runtime weirdness
where objc_lookup_class("NSString") returns a bad class variable,
i've tracked it somewhat setting watchpoints on  class_table_array[52]
and seen the 'correct' class being set as
class_table_array[52]->pointer (where 52 is the hash value for
NSString)

but haven't tracked down where ->pointer goes invalid, it seems to
just have a slight difference where the good one is Ox7.......... and
the bad one OxF.........
but the rest of the class pointer is the same, (at this point the
debugger comes to a halt as it seems to be resorting to software
watchpoints for some reason)

ISTR some old GC code for 'hiding objects' from the garbage collector,
which might account for this, but can't remember where it was (or if
it was even enabled without gc enabled), anyhow if anybody's got any
ideas...




reply via email to

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