LD fails with malloc error on HPUX 11.0

[Carl Erhorn]

During the link of a shared lib, which consists of a large number (>50) C++ object files, we receive the following message:

Malloc is out of memory, leaks over 512k:
/usr/ccs/bin/ld: Out of memory
Malloc: 23013664 bytes allocated by Unknown:0x19403
Malloc: 269746176 bytes allocated by Unknown:0x3c3e7
Malloc: 67436544 bytes allocated by Unknown:0x3c3cb
Malloc: 2286848 bytes allocated by Unknown:0x38f7b
Malloc: 98566656 bytes allocated by Unknown:0x2132f
Malloc: 8421376 bytes allocated by Unknown:0x39c03
*** Error exit code 1

We have increased maxdsize to the maximum that SAM will permit, the system has sufficient swap space (roughly 1GB free), and the shell limits are unlimited for memory use. Data size is 2GB, and maxssize is 8MB.

The ld process bombs when we reach a total memory usage of about 425MB for ld.

Any ideas how to solve this problem? It's been mentioned before, but no one has listed the causes for this error, or steps to take to resolve it.

I'm stuck, can anyone help?

Thanks,Carl

[A. Clay Stephenson]

Hi Carl,

This is puzzling. I did find a new patch PHSS_23440 which does address some memory issues. I would give it a try. The other thing that occurs to me is that rather than being an ld problem it might be a libc problem. I think you should create a small c program which malloc()'s about 10MB repeatedly until it return NULL. At that point check the total allocated memory and errno and see it they are what you expect. I would create both a 32-bit version and a 64-bit version and let them self-destruct.

Happy Hunting, Clay

[Carl Erhorn]

A very good suggestion. I did this, allocating memory in 1MB blocks up to 2GB, while watching for an error.

At 456MB, malloc failed! Yet the shell limit command says data size may be 2GB, stack size may be 128MB, and we checked maxdsiz, maxssiz, and maxtsiz. All we set very generously, with
maxdsiz at 2GB.

We had over 800MB free in virtual memory when
the error occurred. I ran TOP during the run, and saw that the system had over 1.2GB free at the start of the run. So this all makes sense, except why malloc failed at such a low number.

Anyone have any clues?

Thanks,
--Carl

[Magdi KAMAL]

Hi ,

you must increase your swap space.
The formula is :

swap = three to four times the amount of physical memory.

Magdi

[Carl Erhorn]

Note: I'm the original poster, but the forum apparently lost my ID, so I reregistered with a new ID. Sorry if this causes any confusion.

OK - here's the story. I've been able to get past my problem for now, but only by a little. I adjusted the kernel parameters, built a new kernal that gives me about 20MB more memory per process, and installed it. That got me past the problem, but only until my app grows past the new maximum.

I need a better understanding of how HPUX sets the maximum data segment memory for a process. This is the wall I'm hitting. I have plenty of swap space, and in fact can run at least three instances of my 520MB process at the same time, and still have free swap space.

But a simple program that attempts to malloc all available memory says that 512MB is the maximum I can allocate within a single process.

So how do I increase this in HPUX 11.0? I have 1GB physical memory, and about 1.8 GB of swap space. Yet no individual process can malloc more than 512MB. Where is this wall coming from? Maxdsiz, maxtsiz, and maxssiz are all set to reasonable and recommended sizes, and swapmem_on is 1. Ulimit says datasize is 1GB, but no program seems to be able to get there.

I'd appreciate it if someone who really knows this stuff could provide either a good description of how this works, or a step-by-step for a dummy like me.

I'm used to real VM systems, where swap is what you set it to, and there is no limit up to the available swap space. The approach used by HP is totally new to me, because I had never hit the problem before (I'm a developer, not a sysadmin.)

Thanks in advance for any help,
--Carl

[Magdi KAMAL]

Hi again Carl,

Perhaps my response is too small, but it will fix your problem.

As in my last response :

Increase your swap space; you told that you got 1.8GB swap for 1GB RAM ... That's really not enough for such competition on memory.

Formula to follow :

Swap space = 4 times physical memory.

So, to erase this problem, you need 4GB swap space ( on multiple logical volumes will increase performance ).

Magdi

[Carl Erhorn]

Hi, Magdi, and thank you for your help.

I'm a little confused - I do understand that
this is too little swap space, but I would have
expected the addition of 1GB of swap to do
_something_ to the maximum available memory.

As far as my test program shows, there was no
change at all when I added 1GB more swap. So,
moving to 4GB of swap doesn't hold out much hope of an improvement.

Can you tell me why there was no effect in the
maximum size of data I can allocate, when I add 1GB of swap? I don't understand this.

Regards,
--Carl

[Vincent Fleming]

I found this on docs.hp.com:

If you are linking any C++ object files to create an executable or a shared library, you must use the CC command to link. This ensures that c++patch executes and chains together your nonlocal static constructors and destructors. If you use ld, the library or executable may not work correctly and you will probably not get any error messages. For more information see the HP C++ Programmer's Guide .

So, try using CC instead of LD to perform the link. Perhaps this is your problem.

[Vincent Fleming]

Carl,

The other similar question was answered with a resolution. See http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xd36937f45ef7d4118fef0090279cd0f9,00.html
for details.

Good luck!

[Carl Erhorn]

Back again....

Thanks for the thought, Vincent, but yes, I was using the C++ interface to ld all along. I knew of the bug with templates and ld, so we use the C++ driver, and pass any linker switches in with the -Wl,xxx options.

No one seems to know exactly what factors are contributing to the total memory available to a single process that mallocs memory. Sure, it depends on installed ram, maxdsiz, maxssiz, and maxtsiz, and other things too. Swap space, both primary and secondary, swapmem_on settings, etc, all affect this.

But what I would like to know is exactly the factors that contribute to determining the available max memory, and how to adjust these.

Someone had suggested that I have way to little swap space. So I added 1GB to the swap. Surprise! Absolutely no difference in the max memory available to a process.

This seems to be an area of black magic, and perhaps it's too involved to go into on a forum.

I am now working around the problem with some recent kernel changes, which resulted in me being able to malloc up to 512MB of data within a specific instance of a program (any program).

But I'm concerned that with 1GB of real memory, and almost 2GB of swap, that I cannot get a program to be able to malloc more than 512MB. Since I can't get a straight answer as to why this is true, I'm wondering if maybe it's just too involved a topic for anyone to try to make a simple answer to.

But thanks to all who have contributed to the workaround. It's nice to have the help.

Best regards,
--Carl

[A. Clay Stephenson]

Hi Carl:

Maxdsiz and maxdsiz_64 are the only limits on how much space you should be able to allocate (assuming you have sufficient swap).

The first thing to be aware of is that top
only show the memory in use by processes. Kernel memory is not included (e.g. buffer cache). You really can't use top as a means of showing available memory. I assume you have looked at maxdsiz with sysdef. I would now add more swap as filesystem swap with low priority.
This can be done 'on the fly' and does not require a reboot. Run you malloc program and see what happens. I spent about 5 minutes creating and testing one of my own under 64-bit 11.0 (maxdsiz 640MB maxdsiz_64 1GB). Both the 32-bit and 64-bit versions died exactly as expected. I tried both the ANSI/C and aCC compilers and both behaved the same. I am at the latest General Release Patch level. If you are not at that level, I would apply the General Release patchset first.

My one thought is that you have that dreaded dynamic buffer cache enabled and max_dbc_pct set to the default 50%; if so, lower it to about 10% with min at 5% and see what happens,

Regards, Clay

[Carl Erhorn]

I have dbc_min_pct and dbc_max_pct set to 2%. And yes, swapmem_on is set to 1.

These settings were done by my admin, as I am
just a lowly developer. So I really don't have a good understanding of the implications down to a very detailed level. However, I did understand that 50% min and max are are very bad choice, from what I've learned here.

By the way, this system is running 32-bit mode only, so the _64-bit issues don't apply.

You mention that your test program failed just where expected. Do you mean that like mine, you hit a spot where you cannot malloc any additional memory?

--Carl

[A. Clay Stephenson]

Hi Carl:

What I meant was that both the 32-bit and 64-bit versions died with ENOMEM at 640 MB and 1024 MB exactly where I have maxdsiz and maxdsiz_64 set on this box. My little memtest program does nothing but malloc until malloc returned NULL. What I am trying to say is that the memory allocation worked and behaved as expected. One important point is that I did no free()'s ; no reallocs(), just malloc(1MB) after malloc(1MB) until it returned NULL. I don't have enough memory in my only 32-bit 11.0 to really test this but the 64-bit versions seems just fine.

Clay

Clay