Sponsored Content
Operating Systems AIX Coredump in _Init when used dlopen() on AIX 6.1 Post 302429377 by erra_krishna on Monday 14th of June 2010 09:29:46 AM
Old 06-14-2010
Coredump in _Init when used dlopen() on AIX 6.1

Hello,
One of our Customer is getting Coredump when our application is trying to load a library(one of our products library) using dlopen() on AIX 6.1.

Our application and our shared library are built on AIX 5.3 machine using xlC compiler.

we have tried executing the same application on our in-house AIX 6.1 machine and we didn't get any issues . Everything working fine.

Problem is with the Customer's Environment.
Customer OSlevel is 6100-02


Here is the stack trace. It shows, core dump occured in __Init().

Code:
dbx) where
_Init()() at 0xd12bbfbc
strstrea.locale()(??) at 0xd12c3320
strstrea.basic_streambuf()(??) at 0xd12cd0c0
iostream.basic_filebuf(FILE*)(??, ??) at 0xd12ccfb4
Init()(??) at 0xd12ccdd0
__sinit00000164_x_2fbuild_2fvacpp_2f101_2fC_2b_2b_2ert_2e101_2eaix_2dprod_2dopt_2fcpprt_2fsxl_2fstatics_2ecpp()() at 0xd12b6bb0
__catchThrownException() at 0xd0c32b6c
initialize_one_library(??, ??) at 0xd01a8ebc
grab_orig_libs(??) at 0xd01a8678
loadAndInit(??, ??, ??) at 0xd01aaa50
dlopen(??, ??) at 0xd0196648
cliv2_tdicu_init(), line 130 in "loadtdicu.c"
LoadDeps(), line 16882 in "cliv2.c"
DBCHINI(ReturnCode = 0x2ff21518, dummyptr = (nil), dbcptr = 0x30869000), line 9409 in "cliv2.c"
btqInitCapRC(ReturnCode = 0x2ff21518), line 1904 in "btqmfun.c"
btqInitMain(ReturnCode = 0x2ff21518), line 2181 in "btqmfun.c"
main(argc = 1, argv = 0x2ff21a30), line 1854 in "btqmain.c"
(dbx)

we have used dlopen as
Code:
dlopen(ourlibrary,RTLD_GLOBAL | RTLD_LAZY);

Could you let me know what could be the problem.
Is this a know issue OR Customer Machine is missing any filesets.


Thanks in advance.

regards,
Srikrishna Erra.

Moderator's Comments:
Mod Comment Use code tags please, ty.

Last edited by zaxxon; 06-14-2010 at 12:25 PM.. Reason: code tags
 

10 More Discussions You Might Find Interesting

1. Solaris

dlopen issue with a dll

HI All, I am trying to use a dll using dlopen but in vain. When I try to ldd that dll it returns no output. Can anybody please tell me how I can load this dll in my process space. PS: ldd -l returns a lot of unsatisfied dependent symbols. Thanks a lot in advance Codeman (0 Replies)
Discussion started by: codeman
0 Replies

2. Programming

dlopen failed!

I can open my so file successfully by calling dlopen directly in my main function. But if I fork a child process, and call dlopen in child process, it failed! I don't know why. Following is my code: #include <stdio.h> #include <errno.h> #include <dlfcn.h> void childFunc(void) { void... (1 Reply)
Discussion started by: virmin
1 Replies

3. Programming

default location of libs in dlopen

Hi Where is the default location of libs to search, when we specify any lib in dlopen function. And if we want to specify a custom location, how will we do it? thanks. (1 Reply)
Discussion started by: sumsin
1 Replies

4. Programming

compile error while using dlopen

Hi unix lovers, I am getting error while compile a function which uses dlopen. My code is I am getting error as follows Am I missing something? I think I am missing a lot :-) I am using solaris. Thanks in advance, -Ashish (5 Replies)
Discussion started by: shriashishpatil
5 Replies

5. Programming

resolve_symbols: loader error: dlopen:

when i try to run an executable i got the following error message: resolve_symbols: loader error: dlopen: what does this error mean and what should be done to avoid this? with regards (1 Reply)
Discussion started by: gfhgfnhhn
1 Replies

6. Programming

dlopen help

//foo.c #include<stdio.h> int pen(int a) { printf("%d",a); } $cc -c foo.c $ls -shared -o libfoo.so foo.o ///////////now libfoo.so formed //i have already designed libfoo.so //main.c #include<stdio.h> #include <dlfcn.h> int main() { (2 Replies)
Discussion started by: lookforlohith
2 Replies

7. Solaris

dlopen() on dolaris

Dear experts, please help #include <stdio.h> #include <dlfcn.h> #include <link.h> #include <iostream.h> #include<stdlib.h> #include<errno.h> void main() { printf("\n in the main\n"); void *handle; handle = dlopen("my.so", RTLD_LAZY); if( handle ==... (2 Replies)
Discussion started by: vin_pll
2 Replies

8. Programming

Dynamic library load with dlopen

Hi, I created two library libsum.so and libproduct.so. In the libproduct.so is defined function "product" that use function "sum" defined in libsum.so. So libproduct depends on libsum. In main function I called product function by a dlopen request. Unfortunaly, when I execute program I have an... (5 Replies)
Discussion started by: shade82
5 Replies

9. Programming

Linux: dlopen fails to find symbols

I've attached a tar.gz containing three tests to demonstrate the problem I'm having. Within the tar are two shared libraries, two test applications, and a Makefile that builds the three tests. The shared libaries are libshlib1.so and libshlib2.so. Both export a function, libFunc, which takes... (5 Replies)
Discussion started by: DreamWarrior
5 Replies

10. Programming

dlopen Linux vs. OSX

I've got a C++ program and some plugins ( shared objects ) that I have been developing for Linux. I was originally using and OSX machine to develop and test most of the code. I use dlopen to open the shared objects and then call methods from them. It behaves differently on Linux ( don't know the... (3 Replies)
Discussion started by: rfkrakora
3 Replies
dlclose(3)						     Library Functions Manual							dlclose(3)

NAME
dlclose - Close a dlopen() object SYNOPSIS
#include <dlfcn.h> int dlclose(void *handle) PARAMETERS
A pointer to a global symbol object that is returned from a call to dlopen(). DESCRIPTION
The dlclose function is used to inform the system that the object referenced by a handle returned from a previous dlopen() invocation is no longer needed by the application. The use of dlclose() reflects a statement of intent on the part of the process, but does not create any requirements on the dynamic library loader, such as removal of the code or symbols referenced by handle. Once an object has been closed using dlclose(), an application should assume that its symbols are no longer available to dlsym(). All objects loaded automatically as a result of invoking dlopen() on the refer- enced object are also closed. The dlclose function deallocates the address space for the library corresponding to handle. The results are undefined if any user function continues to call a symbol resolved in the address space of a library that has since been deallocated by dlclose. The dlclose operation will not remove an object to which references have been relocated, until or unless all such references are removed. For instance, an object that had been loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might provide a target for dynamic relocations performed in the processing of other objects - in such environments, an application may assume that no relocation, once made, will be undone or remade unless the object requiring the relocation has itself been removed. RETURN VALUE
If the referenced object was successfully closed, dlclose() returns 0. If the object could not be closed or if handle does not refer to an open object, dlclose() returns a non-zero value. More detailed diagnostic information will be available through dlerror(). ERRORS
No errors are defined. NOTES
The dlopen and dlclose routines might dynamically change the resolution of certain symbols referenced by a program or its shared library dependencies. The dlopen routine might resolve symbols that were previously unresolved, and dlclose might cause resolved symbols to become unresolved or to be reresolved to a different symbol definition. A portable application will employ a handle returned from a dlopen() invocation only within a given scope bracketed by the dlopen() and dlclose() operations. The dynamic library loader is free to use reference counting or other techniques such that multiple calls to dlopen() referencing the same object may return the same object for handle. The dynamic library loader is also free to re-use a handle. For these reasons, the value of a handle must be treated as an opaque object by the application, used only in calls to dlsym() and dlclose(). RELATED INFORMATION
dlerror(3), dlopen(3), dlsym(3). delim off dlclose(3)
All times are GMT -4. The time now is 09:02 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy