ladebug heap exhausted

[Travis Craig]

I'm using ladebug on a corefile and it says, on startup:

Welcome to the Ladebug Debugger Version 69 (built May 4 2003 for Tru64 UNIX)
------------------
object file name: myexecutable
core file name: core.myexecutable
Reading symbolic information ...done
Core file produced from executable 'myexecutable'
ALLO 0x0..0xffffffff91304000 : mallocCnt = 3223013
Internal Error: out of memory
Heap exhausted with 47031456 bytes.

Is anybody familiar with this problem and do you know how to fix it? I notice that it is around 47 MB, which seems pretty small to run out of memory. Sizes of other files are:

myexecutable: 35 MB
corefile: 337 MB
shared libraries: 30 MB

When I don't have the shared libraries available, then it complains about that but does not run out of heap space.

--Travis Craig

P.S. Let me know if this thread belongs in a different topic area. This is my first post in the UNIX realm.

[Venkatesh BL]

Does 'dbx' open the file properly?

[Travis Craig]

It's hard to tell whether dbx works or not. I think mostly not. It says there was a segmentation fault in the program that core-dumped, which is true. It gives a short call stack in response to the where command, as ladebug does when I don't have the shared libraries there. Then it says:
DBX Fault: Segmentation fault
It says the same thing in responsed to the "help where" command, so I think dbx is not working well.

I forgot to mention that ladebug does not run into problems when it is run on the same corefile on the machine where the problem occurred. My ladebug problems only happen when I copy the corefile, executable, and shared libraries to my own machine and run it on them there. On the machine where the problem occurred, the call stack of the thread that faulted has around 25 levels. On my machine, without the shared libraries there, it has around 6. Dbx showed 5 levels.

I ran dbx on the corefile produced when ladebug aborted, just to see what dbx looks like on a corefile that was locally produced. It showed 4 levels in the call stack. When I ran ladebug on its own corefile, I saw 31 levels in the call stack, so it appears that dbx and ladebug work differently anyway and I wonder how good a test it is to run dbx on my problematic corefile.

--Travis

[Venkatesh BL]

What is the OS version of the source machine and yours?. These tools could refer to some of the system files to interpret the content of the core file. I am wondering if they are misintepreting the file due to incompatible OS versions.

[Ralf Puchner]

debugging must be done on the same machine due to different memory addresses. In case of shared libraries all versions must match with your machine or output will be totally different!

Be sure you have copied the files properly (bin-mode) and heap memory is large enough for ladebug. dbx ist the primary tool for analyzing, ladebug need more resources due to additional functionality (ladebug is mostly used for program development, dbx for crashes).

[Sri_10]

Make sure process limits are checked as well. Suggest to have higher process limits for data and stack sizes (limit/ulimit in different shells)

If you need to increase hard-limits, you may need to increase them via sysconfigtab proc: sub-section and then reboot.

Thanks
Sri