Re: problem with gnustep on OpenBSD sparc64

[Sebastian Reitenbach]

HI,

I recompiled everything, now linking against libobjc2-1.4, now it also breaks 
consistently, but differently:

$ gdb Affiche 
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) r
Starting program: /usr/local/bin/Affiche 

Program received signal SIGBUS, Bus error.
round_up (v=0xfffffffffffe9e7c, b=32) at encoding2.c:138
138             if (*v % b)
(gdb) bt
#0  round_up (v=0xfffffffffffe9e7c, b=32) at encoding2.c:138
#1  0x000000020f7403dc in sizeof_type (type=0x20563c30c "i]]", 
size=0xfffffffffffe9e7c) at type_encoding_cases.h:20
#2  0x000000020f740074 in parse_array (type=0xfffffffffffe9e70, 
callback=0x20f740320 <sizeof_type>, 
    context=0xfffffffffffe9e7c) at encoding2.c:79
#3  0x000000020f7404bc in sizeof_type (type=0x20563c30a "[4i]]", 
size=0xfffffffffffea01c) at encoding2.c:196
#4  0x000000020f740074 in parse_array (type=0xfffffffffffea010, 
callback=0x20f740320 <sizeof_type>, 
    context=0xfffffffffffea01c) at encoding2.c:79
#5  0x000000020f7404bc in sizeof_type (type=0x20563c308 "[3[4i]]", 
size=0xfffffffffffea0e8) at encoding2.c:196
#6  0x000000020f740694 in objc_sizeof_type (type=0x20563c308 "[3[4i]]") at 
encoding2.c:319
#7  0x000000020f740c54 in objc_compute_ivar_offsets (class=0x205643198) at 
ivar.c:79
#8  0x000000020f73d7b4 in objc_resolve_class (cls=0x205643198) at 
class_table.c:239
#9  0x000000020f73d8ec in objc_resolve_class_links () at class_table.c:260
#10 0x000000020f740fc4 in __objc_exec_class (module=Variable "module" is not 
available.
) at loader.c:90
#11 0x00000002050da2f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
#12 0x00000002050da2f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
Previous frame identical to this frame (corrupt stack?)
(gdb) frame 0
#0  round_up (v=0xfffffffffffe9e7c, b=32) at encoding2.c:138
138             if (*v % b)
(gdb) list
133             if (0 == b)
134             {
135                     return;
136             }
137     
138             if (*v % b)
139             {
140                     *v += b - (*v % b);
141             }
142     }
(gdb) print *v
$1 = 4294967295
(gdb) print b
$2 = 32
(gdb) print *v % b
$3 = 31
(gdb) c
Continuing.




$ 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) r
Starting program: /usr/local/bin/AddressManager 

Program received signal SIGBUS, Bus error.
round_up (v=0xfffffffffffc554c, b=32) at encoding2.c:138
138             if (*v % b)
(gdb) bt
#0  round_up (v=0xfffffffffffc554c, b=32) at encoding2.c:138
#1  0x00000002064e43dc in sizeof_type (type=0x20dcf830c "i]]", 
size=0xfffffffffffc554c) at type_encoding_cases.h:20
#2  0x00000002064e4074 in parse_array (type=0xfffffffffffc5540, 
callback=0x2064e4320 <sizeof_type>, 
    context=0xfffffffffffc554c) at encoding2.c:79
#3  0x00000002064e44bc in sizeof_type (type=0x20dcf830a "[4i]]", 
size=0xfffffffffffc56ec) at encoding2.c:196
#4  0x00000002064e4074 in parse_array (type=0xfffffffffffc56e0, 
callback=0x2064e4320 <sizeof_type>, 
    context=0xfffffffffffc56ec) at encoding2.c:79
#5  0x00000002064e44bc in sizeof_type (type=0x20dcf8308 "[3[4i]]", 
size=0xfffffffffffc57b8) at encoding2.c:196
#6  0x00000002064e4694 in objc_sizeof_type (type=0x20dcf8308 "[3[4i]]") at 
encoding2.c:319
#7  0x00000002064e4c54 in objc_compute_ivar_offsets (class=0x20dcff198) at 
ivar.c:79
#8  0x00000002064e17b4 in objc_resolve_class (cls=0x20dcff198) at 
class_table.c:239
#9  0x00000002064e18ec in objc_resolve_class_links () at class_table.c:260
#10 0x00000002064e4fc4 in __objc_exec_class (module=Variable "module" is not 
available.
) at loader.c:90
#11 0x000000020d7962f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
#12 0x000000020d7962f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
Previous frame identical to this frame (corrupt stack?)
(gdb) frame 0
#0  round_up (v=0xfffffffffffc554c, b=32) at encoding2.c:138
138             if (*v % b)
(gdb) list
133             if (0 == b)
134             {
135                     return;
136             }
137     
138             if (*v % b)
139             {
140                     *v += b - (*v % b);
141             }
142     }
(gdb) print *v
$1 = 0
(gdb) print b
$2 = 32
(gdb) print *v % b
$3 = 0
(gdb) 


I'll check out libobjc2 from svn tomorrow, and try again with that one...


Sebastian


On Tuesday, July 5, 2011 13:30 CEST, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote: 
 
> Hi,
> 
> attached output from gnustep-tests on gnustep-base.
> 
> Sebastian
> 
>  
> On Tuesday, July 5, 2011 12:46 CEST, "Sebastian Reitenbach" 
> <sebastia@l00-bugdead-prods.de> wrote: 
>  
> > Hi,
> > 
> > since I had the question regarding the thread without answer: "problem with 
> > libobc1 on OpenBSD amd64 cannot find tconfig.h when compiling", I thought 
> > about trying it on sparc64. There I ended up with the same problem, no 
> > tconfig.h in config/sparc64/generic...
> > 
> > I copied the tconfig.h file from sparc, which is essentially the same as in 
> > the i386 into config/sparc64/generic, and it was compiling. However, I 
> > found that more or less all applications I tried are aborting with a core 
> > dump. I then tried to change the BITS_PER_WORD to 64, and reinstalled the 
> > old libobjc, but the abort stayed as is. I then uninstalled libobjc1, and 
> > just linked against the system libobjc from gcc-4.2.1.
> > Both with gnustep libobjc1 and gcc libobjc works well on i386. and also 
> > with the gnustep libobjc1, everything works well on sparc 32 bits.
> > 
> > in contrast to mips64, libffi seems to be fine on sparc64:
> > 
> > ===>  Regression check for libffi-3.0.9
> > Making check in include
> > Making check in testsuite
> > make  check-DEJAGNU
> > Making a new site.exp file...
> > srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd . && pwd`; export srcdir;  
> > EXPECT=`if [ -f ../../expect/expect ] ; then  echo ../../expect/expect ;  
> > else echo expect ; fi`; export EXPECT;  runtest=`if [ -f 
> > ../../dejagnu/runtest ] ; then  echo ../../dejagnu/runtest ;  else echo 
> > runtest; fi`;  if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then  
> > exit_status=0; l='libffi'; for tool in $l; do  if $runtest  --tool $tool 
> > --srcdir $srcdir ;  then :; else exit_status=1; fi;  done;  else echo 
> > "WARNING: could not find \`runtest'" 1>&2; :; fi;  exit $exit_status
> > WARNING: Couldn't find the global config file.
> > WARNING: Couldn't find tool init file
> > Test Run By sebastia on Tue Jul  5 11:56:14 2011
> > Native configuration is sparc64-unknown-openbsd4.9
> > 
> >                 === libffi tests ===
> > 
> > Schedule of variations:
> >     unix
> > 
> > Running target unix
> > Using /usr/local/share/dejagnu/baseboards/unix.exp as board description 
> > file for target.
> > Using /usr/local/share/dejagnu/config/unix.exp as generic interface file 
> > for target.
> > Using 
> > /home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/config/default.exp as 
> > tool-and-target-specific interface file.
> > Running 
> > /home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/libffi.call/call.exp 
> > ...
> > Running 
> > /home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/libffi.special/special.exp
> >  ...
> > 
> >                 === libffi Summary ===
> > 
> > # of expected passes            1624
> > # of expected failures          10
> > # of unsupported tests          15
> > Making check in man
> > 
> > 
> > libffi-3.0.9, gnustep-make-2.6.1, gnustep-base-1.22.1, gnustep-gui-0.20.0, 
> > gnustep-back-0.20.1.
> > 
> > running for example AddressManager in gdb, leads to the attached backtrace. 
> > There I see the __smash_stack_handler is thrown:
> > (gdb) bt
> > #0  __stack_smash_handler (func=0x20be18858 "-[GSTimeZone 
> > initWithName:data:]", damaged=201031256) at 
> > /usr/src/lib/libc/sys/stack_protector.c:91
> > #1  0x000000020bbab57c in -[GSTimeZone initWithName:data:] 
> > (self=0x208f3f110, _cmd=0xe, name=0x208f3dd50, data=0xfffffffffffe2310) at 
> > NSTimeZone.m:3110
> > #2  0x000000020bba7930 in -[GSPlaceholderTimeZone initWithName:data:] 
> > (self=0x20a663010, _cmd=0x20bfb7f18, name=0x208f3dd50, data=0x208f3c250) at 
> > NSTimeZone.m:556
> > #3  0x000000020bba5cc4 in -[NSTimeZone initWithName:] (self=Variable "self" 
> > is not available.
> > ...
> > 
> > more information in the attached backtrace and gdb output.
> > 
> > 
> > but I actually cannot see why? Does anybody has a clue?
> > 
> > gnustep-tests on gnustep-base is running right now.
> > BTW: does gnustep-tests has a parameter, where I can prevent it from 
> > cleaning up the binaries after the test? Its because I'd to have them 
> > around, when there are tests leaving a core file, so that I can easily 
> > examine the core file...
> > 
> > 
> > Sebastian
>  
>  
>  
>