[GE users] GE 6.0 vs. Berkeley DB 4.2.52 vs. 64-bit Solaris 9

Greg Earle earle at isolar.DynDNS.ORG
Wed Jul 21 10:15:55 BST 2004


Hi,

I'm new to Grid Engine and the list.  Please be gentle  :-)

I plunged in and built the latest GE 6.0 release on a Solaris 9 machine.

I noticed that by default, it wants to build everything in 64-bit.
My build cruised along until it hit the part where it's supposed to
interface with Berkeley DB 4.2.52, when it complained that my BDB
bits were 32-bit, and everything else was 64-bit.

So, I then tried to build Berkeley DB 4.2.52 as a pure 64-bit version.
I thought "-xarch=v9a" in CFLAGS/CXXFLAGS/LDFLAGS would surely do
the trick, but that wasn't sufficient.  Problems with "libtool" saw
to that.

I ended up getting some 64-bit patches from Sleepycat for 4.2.52
(this is where I started wondering if I was the only person in the
world that had ever run into this) and with those, I was able to do a
successful build & install.

I initialized my qmaster host to use Berkeley DB for the spooling
and set up the RPC server, and tried to fire up the init.d script.

It died at the launching of "berkeley_db_svc".

Now I realize this is out of the realm of GE specifically; it also dies
when run from "/usr/local/BerkeleyDB.4.2/bin/sparcv9/berkeley_db_svc"
as well.  Bear with me a sec ...

To make a long story short, there's a section in the Berkeley DB file
(rpc_server/c/db_server_svc.c) that handles the registering of the DB
service with "portmap" by doing an "svctcp_create(RPC_ANYSOCK, 0, 0)"
followed by a "svc_register()".  To be exact:

         (void) pmap_unset(DB_RPC_SERVERPROG, DB_RPC_SERVERVERS);

         transp = (SVCXPRT *)svctcp_create(RPC_ANYSOCK, 0, 0);
         if (transp == NULL) {
                 fprintf(stderr, "cannot create tcp service.");
                 exit(1);
         }
         if (!svc_register(transp, DB_RPC_SERVERPROG, DB_RPC_SERVERVERS, 
db_rpc_serverprog_4002, IPPROTO_TCP)) {
                 fprintf(stderr, "unable to register (DB_RPC_SERVERPROG, 
DB_RPC_SERVERVERS, tcp).");
                 exit(1);
         }

What's happening to me is that svctcp_create() is returning a
non-NULL value into "transp", but it's not a valid one - it's
returning something like "0x4a300", which can't be accessed (the
binary is a fully 64-bit binary and its memory map starts at
0x100000000).  This inaccessible address gets passed in to the
subsequent "svc_register()", and kablooie - SIGSEGV.  (I've just
reported this behavior to Sleepycat.)

I was going to report to Sun that their /usr/lib/sparcv9/libnsl.so.1
64-bit library has a bogus "svctcp_create()" implementation - but a
degenerate test case that I later made up (a small wrapper around the
above-quoted code, basically) actually works!  The value returned into
"transp" in the test case is 0x100101c90, not 0x4a300.  Very bizarre!
I have no idea why the same exact code would return two drastically
different results.  (libnsl.so.1 is patched up to the latest patchlevel
release, 113319-18.)

Anyway, I'm posting this in the hopes that someone at Sun sees it, for
one; and for another, I'm wondering if perhaps some earlier Grid Engine
developer ran into this as well - I'll note wryly that the "64-bit"
binaries for Solaris 7/8/9 (in "sge-6.0-bin-sol-sparc64.tar.gz")
actually contain 32-bit binaries for the Berkeley DB stuff!  Check it:

isolar:1:67 [/grid] # file utilbin/sol-sparc64/* | grep -v 64-bit
utilbin/sol-sparc64/berkeley_db_svc:    ELF 32-bit MSB executable SPARC
Version 1, dynamically linked, stripped
utilbin/sol-sparc64/db_archive: ELF 32-bit MSB executable SPARC Version
1, dynamically linked, not stripped
utilbin/sol-sparc64/db_checkpoint:      ELF 32-bit MSB executable SPARC
Version 1, dynamically linked, not stripped

Being 32-bit, of course the "berkeley_db_svc" binary in this binary
distribution fires up just fine ...

Am I the only person trying to run a 64-bit Berkeley DB 4.2.52
with Grid Engine 6.0?  Is there even any need or point in doing so?
Anyone?  Anyone?  Bueller?

	- Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list