discuss-gnustep
[Top][All Lists]
Advanced

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

Re: applications segfaulting in gnustep-back on OpenBSD sparc64


From: Sebastian Reitenbach
Subject: Re: applications segfaulting in gnustep-back on OpenBSD sparc64
Date: Sat, 05 Nov 2011 16:17:48 +0100
User-agent: SOGoMail 1.3.9

On Friday, November 4, 2011 20:08 CET, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote:

> Hi Eric,
>
> On Friday, November 4, 2011 19:07 CET, Eric Wasylishen 
> <ewasylishen@gmail.com> wrote:
>
> > That code forgets to check that XRenderFindVisualFormat returns non-NULL. I 
> > committed a fix.
>
> I was also just sitting with gdb, and trying to figure out what the real 
> problem is. I thought that even XRenderFindVisualFormat may have a problem, 
> since it returned NULL.
> I wasn't aware that it is safe for it to return NULL.
>
> So, your fix fixed this problem, but now the next one:
>
> I tried starting Affiche, LapisPuzzle, or AddressManager, all show this 
> exception either on the console, or in a popup window:
>
> NSInternalInconsistencyException REASON:expected array count 32 and got 0 
> INFO:(null)
>
> running LapisPuzze in gdb, I see this:
>
> (gdb) break -[NSException raise]
> Breakpoint 1 at 0x20406e404: file NSException.m, line 956.
> (gdb) bt
> #0  -[NSException raise] (self=0x2024e9b48, _cmd=0x2018087b8) at 
> NSException.m:956
> #1  0x00000002012495f4 in +[NSException raise:format:arguments:] 
> (self=0x201808470, _cmd=0x201808788, name=0x201807f68, format=0x201837118,
>     argList=0xfffffffffffc4590) at NSException.m:849
> #2  0x00000002012494ac in +[NSException raise:format:] (self=0x201808470, 
> _cmd=0x201837d58, name=0x201807f68, format=0x201837118) at NSException.m:835
> #3  0x000000020130dd40 in -[NSPortCoder decodeArrayOfObjCType:count:at:] 
> (self=0x20a914208, _cmd=0x201854480, type=0x2016aaa48 "S", expected=32,
>     buf=0x2024e9b00) at NSPortCoder.m:451
> #4  0x000000020139d624 in -[NSString initWithCoder:] (self=0x20240b7a8, 
> _cmd=0x201837ed8, aCoder=0x20a914208) at NSString.m:5091
> #5  0x000000020130e914 in -[NSPortCoder decodeValueOfObjCType:at:] 
> (self=0x20a914208, _cmd=0x201808848, type=0x20169d8c0 "@", 
> address=0x2024e9050)
>     at NSPortCoder.m:611
> #6  0x000000020124a894 in -[NSException initWithCoder:] (self=0x2024e9048, 
> _cmd=0x201837ed8, aDecoder=0x20a914208) at NSException.m:1060
> #7  0x000000020130e914 in -[NSPortCoder decodeValueOfObjCType:at:] 
> (self=0x20a914208, _cmd=0x2017f05a8, type=0x201698410 "@", 
> address=0xfffffffffffc4b58)
>     at NSPortCoder.m:611
> #8  0x00000002011b5234 in -[NSCoder decodeObject] (self=0x20a914208, 
> _cmd=0x2017f71f0) at NSCoder.m:221
> #9  0x00000002011d3e84 in -[NSConnection(GNUstepExtensions) 
> forwardInvocation:forProxy:] (self=0x20c755648, _cmd=0x2018045d0, 
> inv=0x20a914308,
>     object=0x204164a08) at NSConnection.m:2096
> #10 0x000000020123f628 in -[NSDistantObject forwardInvocation:] 
> (self=0x204164a08, _cmd=0x2018857a8, anInvocation=0x20a914308) at 
> NSDistantObject.m:606
> #11 0x00000002014591d4 in GSFFIInvocationCallback (cif=0x2024a9200, 
> retp=0xfffffffffffc5170, args=0xfffffffffffc5010, user=0x2024e8308)
>     at GSFFIInvocation.m:637
> #12 0x0000000205b7d508 in ffi_closure_sparc_inner_v9 (closure=0x20413e000, 
> rvalue=0xfffffffffffc5170, gpr=0xfffffffffffc5290, fpr=0xfffffffffffc5190)
>     at ../src/sparc/ffi.c:665
> #13 0x0000000205b7d880 in ffi_closure_v9 () from /usr/local/lib/libffi.so.0.0
> #14 0x000000020124444c in -[NSDistributedNotificationCenter 
> addObserver:selector:name:object:suspensionBehavior:] (self=0x2024e8988, 
> _cmd=0x2018065b8,
>     anObserver=0x20c76ede8, aSelector=0x206ebecb0, notificationName=0x0, 
> anObject=0x206ebd4d8, suspensionBehavior=2) at 
> NSDistributedNotificationCenter.m:343
> #15 0x0000000201243e78 in -[NSDistributedNotificationCenter 
> addObserver:selector:name:object:] (self=0x2024e8988, _cmd=0x206ebecc0, 
> anObserver=0x20c76ede8,
>     aSelector=0x206ebecb0, notificationName=0x0, anObject=0x206ebd4d8) at 
> NSDistributedNotificationCenter.m:267
> #16 0x0000000206a85ac8 in -[_GSWorkspaceCenter init] (self=0x20c76ede8, 
> _cmd=0x20182e9b8) at NSWorkspace.m:292
> #17 0x00000002012df170 in +[NSObject new] (self=0x206ebe9c8, 
> _cmd=0x206ebebc0) at NSObject.m:1300
> #18 0x0000000206a8790c in -[NSWorkspace init] (self=0x20f36e388, 
> _cmd=0x206ebec90) at NSWorkspace.m:692
> #19 0x0000000206a874c4 in +[NSWorkspace sharedWorkspace] (self=0x206ebe820, 
> _cmd=0x206dc23c8) at NSWorkspace.m:644
> #20 0x000000020671d940 in -[NSApplication finishLaunching] (self=0x20a8a3808, 
> _cmd=0x206dc2608) at NSApplication.m:1093
> #21 0x0000000206721048 in -[NSApplication run] (self=0x20a8a3808, 
> _cmd=0x206db34b0) at NSApplication.m:1540
> #22 0x00000002066e35d0 in NSApplicationMain (argc=1, argv=0xfffffffffffc5d88) 
> at Functions.m:91
> #23 0x00000000001016d4 in gnustep_base_user_main (argc=1, 
> argv=0xfffffffffffc5d88) at main.m:28
> #24 0x000000020132b328 in main (argc=1, argv=0xfffffffffffc5d88, 
> env=0xfffffffffffc5d98) at NSProcessInfo.m:978
> #25 0x00000000001013cc in _start ()
> #26 0x00000000001013cc in _start ()
> Previous frame identical to this frame (corrupt stack?)
> (gdb) frame 4
> #4  0x000000020139d624 in -[NSString initWithCoder:] (self=0x20240b7a8, 
> _cmd=0x201837ed8, aCoder=0x20a914208) at NSString.m:5091
> 5091                  [aCoder decodeArrayOfObjCType: @encode(unichar)
> (gdb) list
> 5086              if (enc == NSUnicodeStringEncoding)
> 5087                {
> 5088                  unichar   *chars;
> 5089
> 5090                  chars = NSZoneMalloc(zone, count*sizeof(unichar));
> 5091                  [aCoder decodeArrayOfObjCType: @encode(unichar)
> 5092                                          count: count
> 5093                                             at: chars];
> 5094                  self = [self initWithCharactersNoCopy: chars

> 5095                                                 length: count
> (gdb) print count*sizeof(unichar)
> $1 = 64
> (gdb) print chars
> $2 = (unichar *) 0x2024e9b00
> (gdb) print *chars
> $3 = 0
> (gdb) print count
> $4 = 32
> (gdb) frame 3
> #3  0x000000020130dd40 in -[NSPortCoder decodeArrayOfObjCType:count:at:] 
> (self=0x20a914208, _cmd=0x201854480, type=0x2016aaa48 "S", expected=32,
>     buf=0x2024e9b00) at NSPortCoder.m:451
> 451           [NSException raise: NSInternalInconsistencyException
> (gdb) list
> 446           [NSException raise: NSInternalInconsistencyException
> 447                       format: @"expected array and got %s", 
> typeToName2(info)];
> 448         }
> 449       if (count != expected)
> 450         {
> 451           [NSException raise: NSInternalInconsistencyException
> 452                       format: @"expected array count %u and got %u",
> 453                             expected, count];
> 454         }
> 455
> (gdb) print i
> $5 = 2
> (gdb) print offset
> $6 = 0
> (gdb) print size
> $7 = 2
> (gdb) print count
> $8 = 0
> (gdb) print expected
> $9 = 32
> (gdb)
>
> Since there is sth. with unichar, I tried with the default C locale, and also 
> with export LC_CTYPE='en_US.UTF-8'.
> With both, its the same where it now aborts.
>
>
> Sebastian

I tried to look a bit closer at the exception, and tried to compare with i386. 
It seems to take a different code path on i386 and sparc64 in 
-[NSConnection(GNUstepExtensions) forwardInvocation:forProxy:]
on i386, in line 2093 is_exception = 0, on sparc64 it is 1, and then if 
(is_exception == YES) it diverts.
I don't know whether this is actually my problem, but I'd expected both to be 
the same, see the gdb log below.

breakpoint at: -[NSConnection(GNUstepExtensions) forwardInvocation:forProxy:]

when the breakpoint is hit the first time its OK,

on the second time, it then breaks later, so here diving into it:
going on with n sparc 64:
...
1996      type = [[inv methodSignature] methodType];
(gdb)
1997      if (type == 0 || *type == '\0')
(gdb) print type
$2 = 0x209d65fc0 "v64@0:8Q16@24@32@40Q48@56"
going on with n 386:
...
1996      type = [[inv methodSignature] methodType];
(gdb)
1997      if (type == 0 || *type == '\0')
(gdb) print type
$2 = 0x8915b300 "v36@0:4Q8@16@20@24I28@32"

then later it diverts here, see the is_exception difference:
here on sparc64 is_exception=1:
(gdb) list
2087
2088          /*
2089           * Find out if the server is returning an exception instead
2090           * of the return values.
2091           */
2092          [aRmc decodeValueOfObjCType: @encode(BOOL) at: &is_exception];
2093          if (is_exception == YES)
2094            {
2095              /* Decode the exception object, and raise it. */
2096              id exc = [aRmc decodeObject];
(gdb) n
2093          if (is_exception == YES)
(gdb) n
2096              id exc = [aRmc decodeObject];
(gdb) print is_exception
$15 = 1 '\001'
(gdb) print &is_exception
$16 = (BOOL *) 0xfffffffffffc6905 "\001\001"

and on i386 is_exception=0:
2092          [aRmc decodeValueOfObjCType: @encode(BOOL) at: &is_exception];
(gdb) print is_exception
$12 = 180 '´'
(gdb) print &is_exception
$13 = (BOOL *) 0xcfbf00b5 "´\001"
(gdb) n
2093          if (is_exception == YES)
(gdb) n
2103          flags = objc_get_type_qualifiers(type);
(gdb) print is_exception
$14 = 0 '\0'
(gdb) print &is_exception
$15 = (BOOL *) 0xcfbf00b5 ""

now stepping into [aRmc decodeValueOfObjCType: @encode(BOOL) at: 
&is_exception]; on sparc64:
(gdb) s
objc_msg_lookup (receiver=0x209309c08, selector=0x203c9f0c0) at sendmsg2.c:372
372             if (nil == receiver) { return (IMP)nil_method; }

Current language:  auto; currently c
(gdb) print receiver
$1 = 0x209309c08
(gdb) list
367      * Legacy message lookup function.  Does not support fast proxies or 
safe IMP
368      * caching.
369      */
370     IMP objc_msg_lookup(id receiver, SEL selector)
371     {
372             if (nil == receiver) { return (IMP)nil_method; }

373
374             id self = receiver;
375             Slot_t slot = objc_msg_lookup_internal(&self, selector, nil);
376             if (self != receiver)
(gdb) n
374             id self = receiver;
(gdb) n
375             Slot_t slot = objc_msg_lookup_internal(&self, selector, nil);
(gdb) n
376             if (self != receiver)
(gdb) print self
$2 = 0x209309c08
(gdb) print slot
$3 = 0x2011b6960
(gdb) print receiver
$4 = 0x209309c08
(gdb) n
380             return slot->method;
(gdb) s
381     }
(gdb) print
$5 = 0x209309c08
(gdb) list
376             if (self != receiver)
377             {
378                     slot = __objc_msg_forward3(receiver, selector);
379             }
380             return slot->method;
381     }
382
383     IMP objc_msg_lookup_super(struct objc_super *super, SEL selector)
384     {
385             return objc_slot_lookup_super(super, selector)->method;
(gdb)


Then I've seen, in NSPortCoder.m:
- (void) decodeValueOfObjCType: (const char*)type
                            at: (void*)address

      case _GSC_CHR:
      case _GSC_UCHR:
        /* Encoding of chars is not consistant across platforms, so we

           loosen the type checking a little */
        if (*type != type_map[_GSC_CHR] && *type != type_map[_GSC_UCHR])
          {
            [NSException raise: NSInternalInconsistencyException
                        format: @"expected %s and got %s",
                    typeToName1(*type), typeToName2(info)];
          }
        (*_dDesImp)(_src, dDesSel, address, type, &_cursor, nil);
        return;

on the sparc64, address is 1, on the i386, address is 0.

Then again, stepping into (*_dDesImp)(_src, dDesSel, address, type, &_cursor, 
nil);

(gdb)
907             (*_dDesImp)(_src, dDesSel, address, type, &_cursor, nil);
(gdb) s
-[NSDataStatic deserializeDataAt:ofObjCType:atCursor:context:] 
(self=0x20190a388, _cmd=0x202e2fe28, data=0xffffffffffff17f5, type=0x202c91730 
"C", cursor=0x20b12d0b0,
    callback=0x0) at NSData.m:2579
2579    {
(gdb)
...
(gdb) n
2699              getBytes(data, bytes, sizeof(unsigned char), length, cursor);
(gdb) list
2694              return;
2695            }
2696          case _C_CHR:
2697          case _C_UCHR:
2698            {
2699              getBytes(data, bytes, sizeof(unsigned char), length, cursor);
2700              return;
2701            }
2702          case _C_SHT:
2703          case _C_USHT:

there stepping into: getBytes(data, bytes, sizeof(unsigned char), length, 
cursor);
also on the sparc64:

(gdb) s
getBytes (dst=0xffffffffffff17f5, src=0x20b12d500, len=1, limit=252, 
pos=0x20b12d0b0) at NSData.m:2565
2565      if (*pos > limit || len > limit || len+*pos > limit)
(gdb) list
2560    }
2561
2562    static inline void
2563    getBytes(void* dst, void* src, unsigned len, unsigned limit, unsigned 
*pos)
2564    {
2565      if (*pos > limit || len > limit || len+*pos > limit)
2566        {
2567          [NSException raise: NSRangeException
2568                      format: @"Range: (%u, %u) Size: %d",
2569                            *pos, len, limit];
(gdb) print *pos
$8 = 60
(gdb) print limit
$9 = 252
(gdb) print len
$10 = 1
(gdb) print len+*pos
$11 = 61
(gdb) n
2571      memcpy(dst, src + *pos, len);
(gdb) print dst
$12 = (void *) 0xffffffffffff17f5
(gdb) print src
$13 = (void *) 0x20b12d500
(gdb) print (char *)src
$14 = 0x20b12d500 "GNUstep DO archive00000000:00000000:00000000:00000000:%"
(gdb) print (char *)src+*pos
$15 = 0x20b12d53c "\0010\0011\001"                    <------ on i386, this is 
an empty string ""
(gdb) n
2572      *pos += len;
(gdb) print dst
$19 = (void *) 0xffffffffffff17f5
(gdb) print (char *)dst
$20 = 0xffffffffffff17f5 "\001\001"                   <------ on i386, this is 
just ""


I hope someone knows what's going on here, and why its different on i386, and 
on sparc64.

Sebastian



reply via email to

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