--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Fri, Aug 16, 2002 at 02:43:05PM -0400, Andrew Koenig wrote:
> Zack> Can you disable all use of dynamic loading and try the build
> Zack> again? Unfortunately, the only practical way to do this seems
> Zack> to be to edit configure.in and force DYNLOADFILE to be
> Zack> dynload_stub.o (right before the line saying
> Zack> AC_MSG_RESULT($DYNLOADFILE)), then regenerate configure. (Might
> Zack> be a good idea to add an --enable switch.)
>
> As I sort of expected, this makes the crash go away.
Okay, so that pretty much guarantees it's a bug in the toolchain, or
in Solaris ld.so.
> If I put back the dynamic loading stuff and rebuild everything from scratch,
> I again get a python that crashes when I try to import struct.
> It occurs to me that the traceback from that might be useful.
> Needless to say, it is much shorter than the earlier one.
>
> I must say that the "Address 0x2 out of bounds" note makes me suspicious.
That's almost certainly GDB screwing up. In any case,
dynload_shlib.c's version of _PyImport_GetDynLoadFunc does not use
that argument, so that can't be the cause of the problem.
> #0 __register_frame_info_bases (begin=0xfed40000, ob=0xfed40000, tbase=0x0,
> dbase=0x0) at /tmp/build1165/gcc-3.1.1/gcc/unwind-dw2-fde.c:83
Having tbase and dbase be 0x0 is not a problem. The begin and ob
pointers should _not_ be the same. ob should point to a fairly large
data object in the .bss section, and begin should point to the
beginning of the .eh_frame section. This could be GDB screwing up
again, but unwind-dw2-fde.c is compiled with less aggressive
optimization than dynload_shlib.c, so it's more likely to be accurate.
Also, this particular screw-up is a plausible linker or dynamic linker
bug. I suspect struct.so was loaded at address 0xfed40000, which
leaves both these pointers aimed at the beginning of the (unwritable)
.text section -- __r_f_i_b tries to modify the object pointed to by
ob, crash.
Please execute the attached shell script with CC set to your test gcc
3.2 and/or binutils 2.13.x installation and see what happens. If we
do have a toolchain bug, it ought to be provoked by this test.
zw
--2fHTh5uZTiUOsy+g
Content-Type: application/x-sh
Content-Disposition: attachment; filename="test.sh"
Content-Transfer-Encoding: quoted-printable
#! /bin/sh=0A=0Amkdir /tmp/t.$$ || exit 3=0Acd /tmp/t.$$ || exit 3=0A=
=0Acat >main.c <<'EOF'=0A#include <stdio.h>=0A#include <dlfcn.h>=0A=0Aint m=
ain(void)=0A{=0A void *handle, *sym;=0A char *error;=0A=0A puts("c=
alling dlopen");=0A handle =3D dlopen("./dyn.so", RTLD_NOW);=0A if (!=
handle) {=0A printf("%s\n", dlerror());=0A return 1;=0A }=0A=0A =
puts("calling dlsym");=0A sym =3D dlsym(handle, "sym");=0A if ((err=
or =3D dlerror()) !=3D 0) {=0A printf("%s\n", error);=0A return 1;=
=0A }=0A puts("calling sym");=0A ((void (*)(void))sym)();=0A pu=
ts("done");=0A return 0;=0A}=0AEOF=0A=0Acat >dyn.c <<'EOF'=0A#include <s=
tdio.h>=0Avoid sym(void)=0A{=0A puts("in sym");=0A}=0AEOF=0A=0A[ -n "$SH=
FLAGS" ] || SHFLAGS=3D"-fPIC -shared"=0A[ -n "$CC" ] || CC=3Dgcc=0A=0Aset =
-x=0A=0A$CC $CFLAGS $SHFLAGS dyn.c -o dyn.so=0A$CC $CFLAGS main.c -o main -=
ldl=0A=0A./main || exit $?=0A=0Acd /tmp=0Arm -rf t.$$=0A
--2fHTh5uZTiUOsy+g--
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4