dlopen failed : throws fatal: libmtmalloc.so.1: DF_1_NOOPEN tagged object

Hi Folks,

I have this release:

# cat /etc/release

Solaris 10 11/06 s10s_u3wos_09 SPARC

Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.

Use is subject to license terms.

Assembled 01 November 2006

I am trying to use dlopen and it fails with

fatal: libmtmalloc.so.1: DF_1_NOOPEN tagged object may not be dlopen()'ed

Here is the code Snippet.

if (!(handle = dlopen(ptr, RTLD_NOW)))

{

if (errmsg)

*errmsg = dlerror();

return(-1);

}

Where ptr is the pointer to the location of my .so file

Nov 22 11:59:13 shaw Cluster.RGM.rgmd: [ID 375444 daemon.notice] 8 fe_rpc_command: cmd_type(enum):<1>:cmd=</opt/SUNWscims/bin/ims_svc_validate>:tag=&l t;MS_RG.MessagingResource.2>: Calling security_clnt_connect(..., host=<shaw>, sec_type {0:WEAK, 1:STRONG, 2:DES} =<1>, ...)

Nov 22 11:59:13 shaw SC[SUNW.ims,MS_RG,MessagingResource,ims_svc_validate]: [ID 867105 daemon.error] Failed to get the configuration info

Nov 22 11:59:13 shaw ld.so.1: ims_svc_validate: fatal: libmtmalloc.so.1: DF_1_NOOPEN tagged object may not be dlopen()'edAnd the Server root is /opt/shaw/SUNWmsgsr

Nov 22 11:59:13 shaw SC[SUNW.ims,MS_RG,MessagingResource,ims_svc_validate]: [ID 450358 daemon.error] Error retrieving services from iMS configuration

Nov 22 11:59:13 shaw Cluster.RGM.rgmd: [ID 699104 daemon.error] VALIDATE failed on resource <MessagingResource>, resource group <MS_RG>, time used: 0% of timeout <120, seconds>

Message was edited by:

durga.tirunagari

[1632 byte] By [durga.tirunagari] at [2007-11-26 11:40:30]
# 1

if you library has a reference to malloc/free and the application is using libmtmalloc then it might well try to pull

in libmtmalloc.so.1 but that library that it finds in its search path has been modified

using ld with the -z nodlopen flag so it can't be dlopened as part of resolving your

libraries dependancies.

eg if someone runs

# ld -B dynamic -b -G -z nodlopen /usr/lib/libmtmalloc.so.1 -o /tmp/foo.so

# ./dlopen /tmp/foo.so

err ld.so.1: dlopen: fatal: /tmp/foo.so: DF_1_NOOPEN tagged object may not be dlopen()'ed

so if they rename /tmp/foo.so to be libmtmalloc.so.1 and put it in the applications

search path you'd get this effect

I'd start by finding out which mtmalloc.so.1 it is trying to load and then check that against the one shipped which definitely does not have that linker flag set.

truss or pldd might be a place to start.

tim

timuglow at 2007-7-7 11:41:56 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 2

Well, elfdump shows a "NOOPEN" flag for the FLAGS_1 field of /lib/libmtmalloc.so.1.

And it shows this on the Solaris SPARC 8, 9U5, 10U1 systems I quickly looked at.

Is that per chance the -z nodlopen flag? Certainly, my quick test of compiling a

shared library with and without the -z nodlopen specification showed that flag

being activated (or not) in the elfdump output.

So, it would seem that stock Solaris does ship with /libmtmalloc.so.1 set with

-z nodlopen. And, it has done so for quite some time.

dancnewman at 2007-7-7 11:41:56 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 3

Hi,

A quick look in the source shows you are correct, the good news is that

that bugid 6357230 which caused a massive amount of library Makefile rewritting

and simplification removed that flag so solaris > 10 has this removed.

Hope that helps to explain things.

tim

timuglow at 2007-7-7 11:41:57 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 4

Actually I am using the very latest version of Solaris. I still see the problem

# cat /etc/release

Solaris 10 11/06 s10s_u3wos_09 SPARC

Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.

Use is subject to license terms.

Assembled 01 November 2006

Message was edited by:

durga.tirunagari

durgatirunagari at 2007-7-7 11:41:57 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 5

I'm running into a similar problem with libmtmalloc.so.1. I looked on sunsolve

and found bugid #4930536, which dismisses this as 'not a defect', implying

that the flag is set on purpose in libmtmalloc.so.1.

Anyone know more of the reasoning behind this?

Thanks,

Jack D.

JackD at 2007-7-7 11:41:57 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...
# 6

In upgrading iPlanet 6.1 to SP7, I decided to go with a fresh install of 64-bit iPlanet on Sparc Solaris 9.

I receive the following error when the adminsitration server attempts to start:

webservd-wdog: fatal: /usr/lib/libmtmalloc.so: wrong ELF class: ELFCLASS32

Your problem may be 32 - 64 bit compat?

39170 at 2007-7-7 11:41:57 > top of Java-index,Solaris Operating System,Solaris Essentials - General Technical Questions...