Corrupted stack backtrace on Solaris

Could someone explain why the following corrupted stack trace can occur?

Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libxnet.so.1...done.
Loaded symbols for /usr/lib/libxnet.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /opt/csw/lib/libiconv.so.2...done.
Loaded symbols for /opt/csw/lib/libiconv.so.2
Reading symbols from /usr/lib/libcrypt_i.so.1...done.
Loaded symbols for /usr/lib/libcrypt_i.so.1
Reading symbols from /usr/lib/libpthread.so.1...
warning: Lowest section in /usr/lib/libpthread.so.1 is .dynamic at 00000074
done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libm.so.2...done.
Loaded symbols for /usr/lib/libm.so.2
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libc.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libz.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libgen.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from /usr/lib/libaio.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmd.so.1...done.

warning: rw_common (): unable to read at addr 0x0

warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
Loaded symbols for /usr/lib/libmd.so.1
#0  0xfeb3487a in _malloc_unlocked () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfeb3487a in _malloc_unlocked () from /usr/lib/libc.so.1
#1  0x210b5a68 in ?? ()
#2  0xfec0e5d0 in signames () from /usr/lib/libc.so.1
#3  0xfec0d000 in _sys_cldlist () from /usr/lib/libc.so.1
#4  0x08046a28 in ?? ()
#5  0xfeb34704 in _malloc_unlocked () from /usr/lib/libc.so.1
#6  0x00002008 in ?? ()
#7  0x210b5a68 in ?? ()
#8  0x21151b70 in ?? ()
#9  0xfeeda3b0 in ?? () from /usr/lib/libxml2.so.2
#10 0x08046a3c in ?? ()
#11 0xfee03c42 in xmlBufferCreateSize () from /usr/lib/libxml2.so.2
Previous frame inner to this frame (corrupt stack?)

The core occurs from a process built on x86 machine. If the backtrace is performed on the machine executing the process, the backtrace is perfect, with full frame information. However if I do the backtrace with the core on the build machine (a different machine), I the trace above.

One obvious thing I considered was different patch level on the OS One has 5.10 Generic_138889-03(execution machine) and the other has 5.10 Generic_138889-02 (build machine) So the rev number is off. Would this be the reason? Or what else could it be? Anything I can do to see full frame information to allow me to examine core memory in more detail?

Would appreciate any thoughts.

Thanks.

Make sure that you have on the build machine completely the same set of shared libraries as on the computer that is executing the process. If this is not the case copy all shared libraries that are used by your process from the working computer to a folder on the build machine, set LD_LIBRARY_PATH to this folder, start gdb and run bt again.

The full list of relevant shared libraries you can get with the info sharedlibraries command in gdb on the computer that is executing the process.