Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calling dlopen leads to core dump

Status
Not open for further replies.

Vuboy

Programmer
Nov 9, 2004
3
CA
I am writing a program to dynamic call a shared lib routine. I got core dump when dlopen is executed. I am running on Solaris 2.8 SUN-Fire-480R. Any help would be appreciated.
 
Note. I run gdb, here the output:
$ gdb test core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.6"...
Core was generated by `./test'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1...done.
Reading symbols from /home/vnguyen/nncli/nncli/clitest/lib/vu_printf.so...done.
#0 0xff2b3218 in strlen () from /usr/lib/libc.so.1
 
Do you call malloc and/or free at any point before trying to call dlopen ?

If you do, then check all your previous usage of allocated memory. Trashing the memory pool by overstepping your allocated memory bounds is seldom fatal at that moment, but often causes problems in unrelated areas later on in the program.

Try the same thing as a small test program which calls dlopen() (and not much else).

--
 
No, this is a simple test program that only invoke a printf-like in my lib. No things run, here the sample snippet:

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
void* FunctionLib;
void (*FUNCTION)(void);
const char *dlError;

int main(int argc, char* arcgv[]) {
int rc;
printf("Testing dll shared routine\n");
FunctionLib = dlopen("/home/vnguyen/nncli/nncli/clitest/lib/vu_printf.so", RTLD_LAZY);
dlError = dlerror();
.....
}

Further gdb shows:
#0 0xff2b3218 in strlen () from /usr/lib/libc.so.1

 
This works OK on Linux
Code:
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main(int argc, char* arcgv[]) {
  void* FunctionLib;
  const char *dlError;
  void *fn;

  printf("Testing dll shared routine\n");
  FunctionLib = dlopen("/usr/lib/libdl.so", RTLD_LAZY);
  dlError = dlerror();
  printf("%s\n",dlError);

  fn = dlsym(FunctionLib,"dlclose");
  dlError = dlerror();
  printf("%s %p\n",dlError,fn);

  dlclose(FunctionLib);

  return 0;
}

Perhaps you could try with RTLD_NOW to make sure you can actually call routines in your library.
Maybe it's doing something suprising with unresolved symbols.

--
 
If you ldd your executable, is it picking up all the shared libraries from the correct places?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top