[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problem with gnustep on OpenBSD sparc64
From: |
Sebastian Reitenbach |
Subject: |
Re: problem with gnustep on OpenBSD sparc64 |
Date: |
Wed, 06 Jul 2011 11:55:35 +0200 |
User-agent: |
SOGoMail 1.3.7 |
Hi,
I updated libobjc2 to latest svn, and recompiled base, gui, back, and a couple
of applications. I still use the latest releases of those.
libobjc2 was compiled without garbage collection.
Now the programs still crash reproducibly, but in a different way than with
libobc2-1.4.
The abort() is actually triggered from within the code:
$ 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
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 0x000000020662dd64 in objc_compute_ivar_offsets (class=0x209fdb198) at
ivar.c:108
#2 0x000000020662a6f4 in objc_resolve_class (cls=0x209fdb198) at
class_table.c:245
#3 0x000000020662a82c in objc_resolve_class_links () at class_table.c:266
#4 0x000000020662e000 in __objc_exec_class (module=Variable "module" is not
available.
) at loader.c:100
#5 0x0000000209a722f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
#6 0x0000000209a722f0 in ?? () from /usr/local/lib/libgnustep-gui.so.0.20
Previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1 0x000000020662dd64 in objc_compute_ivar_offsets (class=0x209fdb198) 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)
but since I recompiled everything after upgrading libobc2, I wonder what's
wrong here...
anything else I can try to figure out what now the problem is?
Sebastian
On Tuesday, July 5, 2011 22:15 CEST, "Sebastian Reitenbach"
<sebastia@l00-bugdead-prods.de> wrote:
> 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
> >
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
- problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/05
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/05
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/05
- Re: problem with gnustep on OpenBSD sparc64,
Sebastian Reitenbach <=
- Re: problem with gnustep on OpenBSD sparc64, David Chisnall, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, David Chisnall, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, David Chisnall, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, David Chisnall, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, David Chisnall, 2011/07/06
- Re: problem with gnustep on OpenBSD sparc64, Sebastian Reitenbach, 2011/07/06