/usr/lib/dld.sl: Call to mmap() failed

[Remy_1]

Hi,

I'm trying to open up an FTP session on my HP-UX 11.i machine and I'm getting this error.
# ftp localhost
/usr/lib/dld.sl: Call to mmap() failed - TEXT /usr/lib/libsis.sl
/usr/lib/dld.sl: Not enough space
Abort(coredump)
This actually stop other things from working.
Has anyone experienced this problem before? Any help would be greatly appreciated.

Thanks again,
Remy

[Sridhar Bhaskarla]

Hi Remy,

What's your 'swapinfo -tam' out?. Is it at 100%?. If so, then you may need to add more swap space.

Also look at 'dmesg' and /var/adm/syslog/syslog.log files to see if you see any errors related to swap space utilization.

-Sri

[Remy_1]

Hi,

This is my swapinfo -tam output:
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 958 3138 23% 0 - 1 /dev/vg00/lvol2
dev 4096 963 3133 24% 0 - 1 /dev/vg00/swap2
reserve - 2888 -2888
memory 4694 2657 2037 57%
total 12886 7466 5420 58% - 0 -

It looks like it's healthy and my dmesg doesn't indicate any errors.

Thanks again for helping.

Remy

[Sridhar Bhaskarla]

Hi Remy,

Is it only ftp or any other process that is complaining the same?.

Whatlese do you run on your box?. Are they 32bit or 64bit.

-Sri

[Jeff Schussele]

Hi Remy,

What are the kernel parms max?siz set to?
I wonder if you have one abnormally low.
The error indicates it's having trouble with a memory map routine.
Do you have any big 32-bit apps (Oracle?) running?

Rgds,
Jeff

[Remy_1]

Hi,

I'm running a 64bit kernel with 32bit oracle db.
FTP is not the only thing that gives me this error. I get the same thing when I tried to do swlist or compile a file.
As for my maxssiz or maxtsiz parameters, they're set to a very high number. Therefore, I'm not sure if that's the problem.

Thanks again,
Remy

[Sridhar Bhaskarla]

My feeling is that you have a process that has a memory leak and it may be consuming all available data space. Since ftp is a 32-bit program, it is not able to do a mmap().

-Sri

[Sridhar Bhaskarla]

What's your maxdsiz kernel parameter and the setting of oracle SGA?.

-Sri

[Jeff Schussele]

Hi Remy,

Sounds like it's time to start seriously considering one of two things:

1) Starting to use memory windows
or
2) Upgrading Oracle to 64-bit to get address headroom back.

Because you're probably hitting the 32-bit address ceiling.

Rgds,
Jeff

[Remy_1]

Hi Jeff,

I was thinking exactly the same thing.
Not knowing much about oracle, so I'm struggling to find out what it is that caused the problem.
Please let me know if any one had seen this and how to fix it.

Thanks again,
Remy

[James Murtagh]

Hi Remy,

The error is indicating an error mapping a text segment, so either it is related to maxtsiz or the global shared pool. Check not only maxtsiz but maxtsiz_64bit - the 64 bit paramater will limit the 32 bit one if set lower. Thankfully both can be tuned dynamically at 11i so no reboot will be necessary if this is the case. The other factor could be the ~1.75 GB limit on all 32 bit shared objects. As mentioned, Oracle will no doubt be the biggest culprit if this is the caes - use ipcs -mob to check all the shared memory segments or check the SGA size in the Oracle config file. You can also use tusc to trace the process, which will give us the address hence tell us what quadrant is limited.

cheers,

James.

[Jeff Schussele]

Yep - we've all seen it - many times.
32-bit SW can only normally address 1 GB of memory in total per quadrant - 4 quadrants in all, but data, text, stack, shared memory live in separate quadrants & normally don't mix (unless you do option #2 below).

You basically have four options - listed in ease of implementation:

1) Lower the Oracle SGA (System Global area). This is the chunk of memory that Oracle reservers at start. This will leave more memory for other processes

2) Change the Oracle executable to use a MAGIC option which allows it to address more memory by using some memory from another quadrant - do a man chatr for details

3) Implement memory windows which will allow Oracle to have it's own 1GB segment & leave memory for other procs. Note: anything that interacts with Oracle must also be running in that mem window.

4) Upgrade to a 64-bit Oracle version which removes all addressing problems as 64-bit can address Terabytes of data. But don't expect performance gains. 64-bit ia all about addressability - not performance per se.

Rgds,
Jeff

[ranganath ramachandra]

can you get a tusc trace ? also run 'odump -verifyall /usr/lib/libsis.sl' and see if there are any obvious problems with the library itself.