dlopen crashes in 64bit mode

Hi,

I have 64bit C++ shared object built using Sun Fore Compiler(CC) on Solaris 9. However, when I try to open this shared object using dlopen on another Solaris 9 system, it crashes.

I am compiling my code on following system

SunOS 5.9 Generic_118558-30 sun4u sparc SUNW,Sun-Fire-880

and running it on

SunOS 5.9 Generic_118558-34 sun4u sparc SUNW,Sun-Fire-V440

Can any help me figure out what the problem is ?

I get the following in the crash log

Fault signal: SIGSEGV (11), address not mapped to object.

At instruction address 0xffffffff7e74f4a8, faulting access address is 0x61726377396fb9f8

Symbolic location: "realloc + 0x474 [/usr/lib/sparcv9/libc.so.1]"

Thanks in advance

[759 byte] By [dj_phil] at [2007-11-26 11:42:47]
# 1
In such cases I usually try to get more information with LD_DEBUG.You can get all available tracing options with $ LD_DEBUG=help lsand then executing your app with, for example, $ LD_DEBUG=files,detail a.out
MaximKartashev at 2007-7-7 11:49:57 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

Hi,

I have tried that option and I did get some information. After dlopen when I am trying to close using dlclose, the application is crashing. The log is given below.

21694: file=/tmp/test/lib/app/comp/sparcv9/DNSRR.so; dlclose()

21694:

21694: handle=/tmp/test/lib/app/comp/sparcv9/DNSRR.so; collected for possible removal [ GPH_INITIAL ]

21694:

21694: handle=/tmp/test/lib/app/comp/sparcv9/DNSRR.so; deleting:

21694:file=/tmp/test/lib/app/comp/sparcv9/DNSRR.so; object deleting

21694:file=/usr/lib/sparcv9/libCrun.so.1; object removed from handle [ NODELETE ]

21694:file=/usr/lib/64/libc.so.1; object removed from handle [ GLOBAL NODELETE ]

Bus error

21694:file=/usr/lib/64/libdl.so.1; object removed from handle [ GLOBAL NODELETE ]

21694:file=/usr/lib/sparcv9/libCstd.so.1; object deleting

21694:

21694:

21694: notify debugger: event: RD_DLACTIVITY state: RT_DELETE

21694:

21694:

21694: file=/tmp/test/lib/app/comp/sparcv9/DNSRR.so; deleting

21694:

21694: file=/usr/lib/sparcv9/libCstd.so.1; deleting

21694:

21694: notify debugger: event: RD_DLACTIVITY state: RT_CONSISTENT

21694:

21694:

21694: file=/tmp/test/lib/app/bin/sparcv9/STD; add binding to:

21694:file=/usr/lib/64/libsocket.so.1[ NEEDED REFERENCED ]

Fault signal: SIGBUS (10), invalid address alignment.

At instruction address 0xffffffff7dd4f4a8, faulting access address is 0x4e5352532eb264cc

Symbolic location: "realloc + 0x474 [/usr/lib/sparcv9/libc.so.1]"

21694:

21694: ld.so.1: app: fatal: address 0x4e5352532eb264cc does not fall within any mapped object

21694:

Concluding frames leaf call (n=1)

# 00x7dd4f4a8realloc + 0x474 [/usr/lib/sparcv9/libc.so.1]

[0x1,0x1f3620,0x1,0x1f3620,0x1,....]

# 10x7dd4f444realloc + 0x410 [/usr/lib/sparcv9/libc.so.1]

Does this mean that there is a problem with the library /usr/lib/sparcv9/libc.so.1 or /usr/lib/sparcv9/libCstd.so.1 or any other library ?

Thanks in advance

dj_phil at 2007-7-7 11:49:57 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3
It might be that your program corrupts memory, which on one machine doesn't lead to a crash, but on another it does. Try checking your program with dbx command 'check -access'.
MaximKartashev at 2007-7-7 11:49:57 > top of Java-index,Development Tools,Solaris and Linux Development Tools...