Hi Michael, Yes the rgmd is a solaris cluster binary and libclcomm is a solaris cluster shared object.
What I am looking for is what sort of change in these (rgmd, libclcomm) can cause a sigsegv to occur in elf_bndr which is a core solaris operating system routine. I am guessing that there is some sort of memory corruption. Thanks, Tirthankar http://blogs.sun.com/tirthankar Michael Schuster wrote: > Tirthankar wrote: > >> Hi. >> >> I have a core for a userland process. Its a 32bit binary running on >> amd64 machine and the process gets a SIGSEGV in elf_bndr >> >> Any idea why I am hitting such a panic. > > > please be precise and consistent with your terminology, you make other > peoples' lives much easier :-) - we generally use "panic" for kernel > crashes, which this quite clearly isn't, so let's stick with "core" > (which, alas, is used for many things ... but that's a different story) > > IIRC, libclcomm and rgm are terms out of Sun Cluster, so maybe you > want to float this past an appropriate cluster person or alias (add > relevant info such as OS and Sun Cluster versions ...) > > HTH > Michael > >> >> > $G >> C++ symbol demangling enabled >> > $C >> fd8b11cc ld.so.1`elf_bndr+0x217(fecf0f10, a08, fe11ac31) >> fd8b11ec ld.so.1`elf_rtbndr+0x14(a08, fe11ac31, b186568, fd8b14ac, 0, >> 1e) >> fd8b1840 0xfecf0f10(8091548, fd8b187c, fd8b1870, 0, fd8f1ce4) >> fd8b18e0 libclcomm.so.1`void >> _rgm_rgm_comm_idl_scswitch_primaries_receive+0xb1(809154c, fd8b1b04) >> fd8b1934 libclcomm.so.1`void >> remote_handler::handle_incoming_call+0x101(8091550, fd8b1b04) >> fd8f1d20 libclcomm.so.1`void >> solaris_xdoor_server::object_server+0x912(86b89f0, fd8f1d74, 89, 0, >> 0, fe8138e0) >> 00000000 libc.so.1`_door_return+0xb7() >> > >> >> I am guessing that its a linking problem or a memory corruption >> > >
