Core file debugging

turnmeout · 08-11-2008, 04:52 AM

Is there anyway to find memory leak in the core in solaris without using purify tool because purify works only in run-time debugging?

I am hanging out any one help me....

Mr. C. · 08-11-2008, 09:40 AM

You can debug a core file, but you'll have to manually walk the stack, trace data structures, and backtrack from what evidence is available in the core file. It may be easy, or it may be nearly impossible to find a memory leak using a core file - it all depends upon your program's complexity.

jlliagre · 08-11-2008, 12:01 PM

What is preventing you to do run time debugging ?

turnmeout · 08-12-2008, 12:37 AM

Mr. C and jilligare we have generated the core file using gcore and program we using also too complex...

Can you help me there is any tool to find memory leak....At minimal we have to find out there is any memory leak from the core file...

Mr. C. · 08-12-2008, 12:55 AM

I've only used purify and prior to that manual debugging. There are version of malloc that provide some instrumentation and assistance, but those may not be of any help.

Finding a memory leak from a core file is like finding a needle in a haystack. You have to start walking data structures, pointer by pointer.

It would be more productive to instrument your code.

jlliagre · 08-12-2008, 01:37 AM

Yes, give up trying to extract anything from your current core file. This is a dead end. You might use a core file only after the application has been instrumented.

Solaris provides excellent and free tools to investigate memory leaks. Start with libumem.

Run your application with the following script:

Code:

#!/bin/ksh
UMEM_DEBUG=default
UMEM_LOGGING=transaction
LD_PRELOAD=libumem.so.1
/path-to-your-application-here

When you suspect the leak is present, have a look at all the allocated memory with this command :

Code:

$ echo '::findleaks' | mdb -o nostop -p <your-application-process-id> | tee /tmp/leaks.txt

This will display and generate a file named /tmp/leak.txt will all the current memory allocations. Note that they aren't necessarily leaks.

There are several other mdb commands to go further.
Google "mdb findleaks site:blogs.sun.com" for various articles about them.

You can also inspect a core file as long as the process has been started the way I described. Generate that core file with the gcore command or just wait for the OS to create the core if your application is crashing.

turnmeout · 08-12-2008, 01:39 AM

Hello Mr.C,

Our core file is not prepared with purify option and we generated a core using gcore utility.

Can you provide inputs through malloc?

Thanks in advance

jlliagre · 08-13-2008, 03:57 AM

I did. Did you miss my posting ?

Mr. C. · 08-13-2008, 07:59 AM

Quote:

Originally Posted by turnmeout

Hello Mr.C,

Our core file is not prepared with purify option and we generated a core using gcore utility.

Can you provide inputs through malloc?

Jlliagre has responded with very good information, and is far more up to date and knowledgeable on Solaris than I am. I haven't done major Solaris development work in a while now.

turnmeout · 08-13-2008, 11:41 PM

Quote:

Originally Posted by jlliagre

I did. Did you miss my posting ?

Thanks Jilligare,

But I am using Solaris 8, I searched through websites where it is described that libumem.so.1 is not ported to Solaris 8.

We are using a tool which gives the hex dump of the core file from the virtual address where the heap is located.

Now, we are having Hex output of the heap.

We now want to know whether it is possible from the hex dump output.
Allocation of memory area in our program is done by using malloc.

Can you provide me how to proceed?

jlliagre · 08-14-2008, 01:27 AM

Well, as already stated, analysing your core is very unlikely to lead to anything.

Why not simply using Solaris 9 or 10 on a test platform ?

Applications correctly written for Solaris 8 are guaranteed to run on newer releases.

turnmeout · 08-14-2008, 03:03 AM

But jillingare we dont have solaris 9 and 10 test machines...

kebabbert · 08-14-2008, 03:59 AM

You can install Solaris 10 on a commodity cheap x86 machine. Use an old Pentium 4 with 1-2GB RAM. When you have debugged it on the Solaris 10, you can compile on S8 instead.

jlliagre · 08-14-2008, 05:36 AM

Quote:

Originally Posted by turnmeout

But jillingare

My pseudo is often mistyped but with that one you really win

Quote:

we dont have solaris 9 and 10 test machines...

Just build one. Solaris 10 is free after all.

javier.e.menendez · 08-16-2008, 07:56 AM

Hi Jlliagre:

I have no idea where you got the information that applications written for solaris 8 are "guaranteed" to run on 10.
I have worked for Sun doing technical support in HAS (High Availability Support//25k/20k/15k/12k and sun cluster) and that is NOT accurate. It is called support and we have a long list of what is supported and NOT supported in 10. There is no guarantee that the app that was compiled for 8 will work in 10.

That is one of the reasons why sun came up with solaris 8 and 9 non global zones in 10 via the Migration Assistant. That way, you can run solaris 10 on new machines and install solaris 8 zones to run your old apps in new hardware without having to keep old hardware.

It is a matter of support. Sun does not support old apps written for 8 in 10. They may or may not run but you are talking about lack of support.

Here are some examples:

in sun cluster 3.2 that can only run 10, you can't (we don't support) old versions of oracle. Like 8i. I have tried to install 8i on 10 and it will not work in or out of cluster.

solaris 10 does not support older versions of veritas (only 4.1 and 5.0). So if you try let's say a 3x version of vxvm, it will not work due to library (among others) issues.

Also, if the poster has a memory leak, he should send the core file to the kernel team in Sun (that is what they do) and they will help him (assuming he has a contract) with his issue at least to a point.