From owner-freebsd-hackers  Mon Feb 22 20:13: 4 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id C7F8F10F2E
	for <hackers@FreeBSD.ORG>; Mon, 22 Feb 1999 20:12:24 -0800 (PST)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.2/8.9.2) id UAA72778;
	Mon, 22 Feb 1999 20:10:55 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <199902230410.UAA72778@bubba.whistle.com>
Subject: Re: Interesting ld.so bug
In-Reply-To: <XFMail.990222194002.jdp@polstra.com> from John Polstra at "Feb 22, 99 07:40:02 pm"
To: jdp@polstra.com (John Polstra)
Date: Mon, 22 Feb 1999 20:10:54 -0800 (PST)
Cc: hackers@FreeBSD.ORG, terry@whistle.com
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

John Polstra writes:
> > Now when we run a java class that uses the java_jni.c native method,
> > the call to Java_bar1() succeeds, and the call from there to bar1()
> > succeeds, but when bar1() tries to call bar2(), it jumps to a very
> > low address and segfaults. It seems that the bar2() trampoline is
> > using an uninitialized base address or whatever.
> > 
> > NOW, if we remove "db.c" from the compilation of "libfoo.so",
> > then everything works!
> 
> Was the code in the static libgdbm.a library compiled with -fpic?
> I bet it wasn't, and that's probably the problem.  All code that's
> included in a shared library should be PIC code.

Actually, now something else is going on..  here's some more info:

	      With db.c     Without db.c
	      ---------     ------------

RTLD_LAZY      fails          works!

RTLD_NOW       fails          fails

Terry thinks there is a screwup in RTLD_NOW in that it's failing
to recurse.

Example of failure without db.c:

  Program received signal SIGSEGV, Segmentation fault.
  0x337a in ?? ()
  (gdb) bt
  #0  0x337a in ?? ()
  #1  0x286a3879 in Java_Locat_IjGetLanguage (env=0x280db038, clazz=0x818ef30)
      at java_locat.c:82
  #2  0x816acf0 in ?? ()
  #3  0x81cc49d in ?? ()

Example of failure with db.c:

  Program received signal SIGSEGV, Segmentation fault.
  0x3192 in ?? ()
  (gdb) bt
  #0  0x3192 in ?? ()
  #1  0x816acf0 in ?? ()
  #2  0x81cc49d in ?? ()

Java_Locat_IjGetLanguage is the native routine, and it's trying to
call another routine in the same shared library and dieing. It looks
like the fixup for the second routine (which is also exported) is
not being done for some reason.

However, this can be worked around by adding this to the build
of the library (discoverd by Amancio):

  -export-dynamic -lgdbm -lc

Any ideas on what's going on?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message