Re: problem with gnustep on OpenBSD sparc64

[Sebastian Reitenbach]

On Wednesday, July 6, 2011 12:49 CEST, David Chisnall <theraven@sucs.org> 
wrote: 
 
> 
> On 6 Jul 2011, at 11:45, Sebastian Reitenbach wrote:
> 
> > 
> > On Wednesday, July 6, 2011 12:14 CEST, David Chisnall <theraven@sucs.org> 
> > wrote: 
> > 
> >> On 6 Jul 2011, at 11:02, David Chisnall wrote:
> >> 
> >>> On 6 Jul 2011, at 10:55, Sebastian Reitenbach wrote:
> >>> 
> >>>> Error: Instance variables in NSTextTable overlap superclass NSTextBlock. 
> >>>>  Offset of first instance variable, _layoutAlgorithm, is 196.  Last 
> >>>> instance variable in superclass, _widthType, ends at offset 148.  This 
> >>>> probably means that you are subclassing aclass from a library, which has 
> >>>> changed in a binary-incompatibleway.
> >>> 
> >>> I think this is a bug in how libobjc2 is calculating sizes.  The last 
> >>> ivar of NSTextBlock is an array of arrays, and my guess is that the 
> >>> runtime thinks that it is smaller than it is.
> >> 
> >> Having said that, I can't actually reproduce this, and objc_sizeof_type() 
> >> seems to return the same size as sizeof() for me when I copy the last ivar 
> >> into a file and test it.  
> >> 
> >> Both of these numbers look a bit wrong.  For me, class_getInstanceSize() 
> >> returns 172 for NSTextBlock, so unless you've got some very strict 
> >> alignment requirements 196 looks too large.  The header doesn't seem to 
> >> have been modified for a long time, so I'm not sure how it could happen.
> > IIRC, the alignment is fairly strict on sparc64, but I'm not an expert ;)
> 
> Hmm, 196 might be correct for SPARC64.
> 
> >> Can you tell me from the debugger:
> >> 
> >> - What the type encoding of the last ivar is
> >> - What the calculated size of the last ivar is
> > Do you can give me a hint how I can figure this out? At which frame stack I 
> > should potentially go, or where to set a breakpoint, and what to enter?
> 
> The stack frame that calls abort (objc_compute_ivar_offsets()).  It has a 
> local variable called ivar, which is the last ivar in the superclass.  It 
> uses this to calculate the size from the type.

OK, I have seen this ivar before, but when I set a brekapoint on ivar.c:74, gdb 
doesn't break there, it goes straight to the abort for some reason. Then 
entering the frame, I get to learn, there is no such variable ivar....

$ gdb AddressManager  
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.9"...
(gdb) break ivar.c:74
No source file named ivar.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ivar.c:74) pending.
(gdb) r
Starting program: /usr/local/bin/AddressManager 
Breakpoint 2 at 0x206595c78: file ivar.c, line 74.
Pending breakpoint "ivar.c:74" resolved
Error: Instance variables in NSTextTable overlap superclass NSTextBlock.  
Offset of first instance variable, _layoutAlgorithm, is 196.  Last instance 
variable in superclass, _widthType, ends at offset 148.  This probably means 
that you are subclassing aclass from a library, which has changed in a 
binary-incompatibleway.

Program received signal SIGABRT, Aborted.
abort () at /usr/src/lib/libc/stdlib/abort.c:74
74      /usr/src/lib/libc/stdlib/abort.c: No such file or directory.
        in /usr/src/lib/libc/stdlib/abort.c
(gdb) bt    
#0  abort () at /usr/src/lib/libc/stdlib/abort.c:74
#1  0x0000000206595d64 in objc_compute_ivar_offsets (class=0x20b073198) at 
ivar.c:108
#2  0x00000002065926f4 in objc_resolve_class (cls=0x20b073198) at 
class_table.c:245
#3  0x000000020659282c in objc_resolve_class_links () at class_table.c:266
#4  0x0000000206596000 in __objc_exec_class (module=Variable "module" is not 
available.
) at loader.c:100
#5  0x000000020ab0a2f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
#6  0x000000020ab0a2f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
Previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0x0000000206595d64 in objc_compute_ivar_offsets (class=0x20b073198) at 
ivar.c:108
108                     abort();
(gdb) list  
103                             ivar->name, ivar->offset +
104                             (int)objc_sizeof_type(ivar->type));
105                     fprintf(stderr, "This probably means that you are 
subclassing a"
106                             "class from a library, which has changed in a 
binary-incompatible"
107                             "way.\n");
108                     abort();
109             }
110     }
111     
112     
////////////////////////////////////////////////////////////////////////////////
(gdb) print sizeof(ivar)
$1 = 8
(gdb) print ivar
Variable "ivar" is not available.
(gdb) print sizeof(*ivar)
Variable "ivar" is not available.
(gdb) print ivar->name
Variable "ivar" is not available.
(gdb) list ivar.c:74
69                      /* Find the last superclass with at least one ivar. */
70                      while (NULL == super->ivars) 
71                      {
72                              super = class_getSuperclass(super);
73                      }
74                      struct objc_ivar *ivar =
75                              &super->ivars->ivar_list[super->ivars->count-1];
76      
77                      // Find the end of the last ivar - instance_size 
contains some padding
78                      // for alignment.
(gdb) 


Do you maybe can propose an NSLog() statement that I could add somewhere after 
teh line 74 to print out the values you would like to see?
Easiest would be a patch for me that I can apply and recompile, and report back.


Sebastian


> 
> David
> 
> -- Sent from my IBM 1620
>