[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hpux-devtools
Subject:    RE: HPUX-DEVTOOLS: I get a core dump while trying to call shl_loa
From:       "BENNETT,ANDY (HP-Unitedkingdom,ex1)" <andy_bennett () hp ! com>
Date:       2001-02-23 8:38:36
[Download RAW message or body]

As Dennis says, get a stack trace, tusc output on its own can be misleading
unless you know what the application is expecting from its system calls. In
particular, the dynamic linker is capable of dealing with ENOMEM from mmap()
since it can crop up in every day circumstances. For example, consider a
simple shell script running in a shell:

$ cat hello
echo hello
$ tusc sh hello
execve("/usr/bin/sh", 0x7bfe0734, 0x7bfe0740) .................... = 0
[32-bit]

... skip some start up and
... loading of dld.sl and /opt/graphics/OpenGL/lib/libogltls.sl

open("/usr/lib/libc.2", O_RDONLY, 0) ............................. = 3

... libc.2 gets loaded
... and libdld.2
... and then try to load libc.2 again, mmap fails with ENOMEM because it is
... already loaded

open("/usr/lib/libc.2", O_RDONLY, 0) ............................. = 3
fstat(3, 0x7bfe32a0) ............................................. = 0
read(3, "0210010e0512@ \0\0\0\0\0\0\0\0\0".., 128) ............... = 128
lseek(3, 128, SEEK_SET) .......................................... = 128
read(3, "10\0\004\0\0\0( \012q ec\0\010\0".., 48) ................ = 48
read(3, "80\0\0\v\0\0\004\0\0\0\0", 12) .......................... = 12
lseek(3, 278528, SEEK_SET) ....................................... = 278528
read(3, "058cy 10\0\006e4\0\0G 9c\0\0\002".., 112) ............... = 112
mmap(0, 1212416, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0x44000)
ERR#12 E
NOMEM
close(3) ......................................................... = 0

...

There is no fault in the above, and the shell runs without a problem. While
I am not saying your example is due to a library being loaded several times,
check whether the program has exited shl_load() and hence if that has set an
errno about whether there is a problem. It might be worth adding
BIND_VERBOSE to the flags so that it will print a message if it spots a
problem.


> -----Original Message-----
> From: Dennis Handly [mailto:dhandly@cup.hp.com]
> Sent: 23 February 2001 01:42
> To: hpux-devtools@cxx.cup.hp.com
> Subject: RE: HPUX-DEVTOOLS: I get a core dump while trying to call
> shl_load
> 
> 
> >Do you know in particular the patches that need to be 
> installed to fix this
> >issue.
> 
> No, just try the "latest".
> 
> >But I thought it would be a good idea to separate them out and hence
> >decided to use the shl_load.
> 
> You better have more than just a "good" idea.
> 
> >The reason I know its shl_load is because I traced the 
> application using
> >tusc.
> >I see that shl_load calls open, and then the mmap, mmap 
> fails with ENOMEM.
> Lakshmi
> 
> But you don't know where it aborted.  It may be in libc.
> Always get a stack track.
> But it seems there is something wrong with your system if you 
> get ENOMEM.
> I.e. too much shared memory.  Too many shared libs, etc.
>  _________________________________________________________________
>  To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
>     with the message UNSUBSCRIBE hpux-devtools
>  _________________________________________________________________
> 
 _________________________________________________________________
 To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
    with the message UNSUBSCRIBE hpux-devtools
 _________________________________________________________________

[prev in list] [next in list] [prev in thread] [next in thread]