Hi All, Thanks a lot for the responses. I used libumem to find out where the error occurred. But after I set the variables LD_PRELOAD and UMEM_DEBUG, I found that sometimes the SIGSEGV was gone!!!!....
But this process runs on two machines simultaneously and these two machines communicate about the progress of each process. When SIGSEGV is gone (on the machine where it occurs), I find that other machine gets a SIGABRT signal and the generated core dump shows the following info when I use a mdb to see what's happening.( I have set the variables LD_PRELOAD and UMEM_DEBUG on this machine where I get the following core) mdb core mdb: core file data for mapping at fedd0000 not saved: Interrupted system call mdb: core file data for mapping at fede0000 not saved: Interrupted system call mdb: core file data for mapping at fedf0000 not saved: Interrupted system call mdb: core file data for mapping at fee01000 not saved: Interrupted system call mdb: core file data for mapping at fee10000 not saved: Interrupted system call mdb: core file data for mapping at fee20000 not saved: Interrupted system call mdb: core file data for mapping at feea0000 not saved: Interrupted system call mdb: core file data for mapping at feea5000 not saved: Interrupted system call mdb: core file data for mapping at feeb0000 not saved: Interrupted system call mdb: core file data for mapping at fef76000 not saved: Interrupted system call mdb: core file data for mapping at fef7c000 not saved: Interrupted system call mdb: core file data for mapping at fef80000 not saved: Interrupted system call mdb: core file data for mapping at fef90000 not saved: Interrupted system call mdb: core file data for mapping at fefb5000 not saved: Interrupted system call mdb: core file data for mapping at fefba000 not saved: Interrupted system call mdb: core file data for mapping at fefd0000 not saved: Interrupted system call mdb: core file data for mapping at fefda000 not saved: Interrupted system call mdb: core file data for mapping at feffa000 not saved: Interrupted system call mdb: core file data for mapping at feffb000 not saved: Interrupted system call mdb: warning: librtld_db failed to initialize; shared library information will not be available Loading modules: [ ld.so.1 ] > ::umem_status mdb: invalid command '::umem_status': unknown dcmd name I am not getting as to what can be done further. If I do not set the LD_PRELOAD and UMEM_DEBUG on the machine which has the above core, I find a SIGSEGV similar to the one I reported in my first mail (i.e in _malloc_unlocked() ) function. Please provide me with some inputs as to how can I proceed further? Thanks Priya -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, December 24, 2007 6:21 PM To: [EMAIL PROTECTED] Cc: Vamsee Priya; opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solarisx86 machine On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote: > >> Hi >> I don't find a core dump generated when a SIGSEGV is received. I set the >> LD_PRELOAD variable to watchmalloc.so.1 but could not find the actual >> place of seg. fault as the core dump file is not generated. (I got the >> stack trace I pasted when I attached mdb to the process) I don't have a >> Sun studio compiler to run dbx. >> Any more tools with which I can debug futher? > > You can use "coreadm" to redirect the core someplace. > > Does your program call "chdir()"? If so, the core dump will be elsewhere. > > Note that with watchmalloc.so.1 you will also need to set some other > variables. ... which are, like all good Solaris features, documented in the manpages, watchmalloc(3MALLOC) in that case :) watchmalloc and libumem are somewhat complementary, some problems are easier to track with one some easier with the other. Merry christmas, FrankH. _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
