On Mon, 24 Dec 2007, Vamsee Priya 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
Try libumem, see manpage, usually as simple as:
LD_PRELOAD=libumem.so UMEM_DEBUG=default /path/to/your/program
and then attach mdb to it. If you actually need to run it under mdb
control to start with, then do:
::setenv LD_PRELOAD libumem.so
::setenv UMEM_DEBUG default
::run
If you're not getting coredumps, check the "coreadm" settings for the
machine and/or the process in question. That should tell you where (if not
the current working dir of the process) corefiles would end up. Also check
"ulimit -c" on whether the coredumpsize has been unduly limited.
Once things crash with libumem and umem debugging enabled, rum
"::umem_status" from within mdb.
> Sun studio compiler to run dbx.
> Any more tools with which I can debug futher?
a) check coreadm and ulimit -c settings
b) try libumem and UMEM_DEBUG. See libumem(3LIB).
FrankH.
>
> Thanks
> Priya
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of [EMAIL PROTECTED]
> Sent: Monday, December 24, 2007 2:27 PM
> To: Vamsee Priya
> Cc: opensolaris-discuss@opensolaris.org
> Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on
> Solaris x86 machine
>
>
>> Hi All
>>
>> When I use my 32 bit binary on Solaris x86 machine, I get a
> segmentation
>> fault with the following stack trace.
>>
>> libc.so.1`_malloc_unlocked+0x14c(4000, 3, 80a3130, 1, 8046a38, 805763f)
>> libc.so.1`malloc+0x39(4000, 0, 8046a1c, fef9e455, fef9158c, 4)
>> meta_del+0x13(2, 80a3100, 10, 0)
>> standby_fix+0x75e(2, 8047e8f, 8046b10, 0)
>> standby+0xcc(2, 8047e8f, 0, 0, 8046bc7)
>> main+0xd59(6, 8047d80, 8047d9c)
>> _start+0x80(6, 8047e48, 8047e67, 8047e6a, 8047e7c, 8047e8f)
>>
>
>
> This stacktrace is symptomatic for memory corruption; because the 32 bit
>
> and 64 bit allocators round up differently, it is possible that the
> error
> is masked in 64 bit mode.
>
> Start debugging, e.g., using watchmalloc or libumem or dbx run time
> access
> checking.
>
> Casper
>
>
>
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>
------------------------------------------------------------------------------
No good can come from selling your freedom, not for all the gold in the world,
for the value of this heavenly gift far exceeds that of any fortune on earth.
------------------------------------------------------------------------------
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
