Memory Fault (coredump)

[Des_2]

I have some developers giving me some grief over a coredump message.

The system in question is incredibly old and is running hp-ux 10.10 (which I not allowed to upgrade)

The source code is failing to compile with the following error

/usr/lib/dld.sl: Invalid version for shared library: /usr/lib/libc.1
/usr/lib/dld.sl: Exec format error

Looking into the output we see a coredump has also ocuured.

"file core" giving core file from 'ld' - received SIGSEGV

"what core" giving:

92453-07 linker linker ld A.10.44 950920
HP92453-02A.10.00 HP-UX SYMBOLIC DEBUGGER (END.O) $Revision: 74.03 $
92453-07 dld dld libdld.sl A.10.44 950920
PATCH/10_10 PHCO_16722 $Revision: 76.162.1.14.1.75 $
SMART_BIND
92453-07 dld dld dld.sl A.10.44 950920

"strings core" gives the following parts...

AJ$Revision: 92453-07 linker linker crt0.o A.10.30 940805 $
/usr/lib/dld.sl
ERROR: mmap failed for dld
@(#)92453-07 linker linker ld A.10.44 950920
$START$
a.out
_ELABORATOR
256k
flow.data
/usr/lib
/opt/langtools/lib
Total data space malloc'ed = %d
:
:
:
:
get_sym_mult:1
get_sym_mult:2
ld : Shared Library %s does not have proper static data support.
Rebuild with linker version A.08.30 or later.
shlib internal_name = %s
HP-UX Shlib Export stub to %s
Shared Library
WARNING: LIBRARY %s HAS OVERFLOW SYMBOLS; USE CLEANRL
WARNING: LIBRARY %s HAS OVERFLOW STRINGS; USE CLEANRL
$BSS$
%.10ld %c %s
:
:
:
:
/var/tmp
Warn - %s alignment forced to smaller value
Starting subspace sort...
End subspace sort (%d ms. real, %d ms. user)
NULL_SYMBOL_OF_DEATH
switched code and entry for %s
ind: %d sym_ind: %d
:
:

I have a feeling this is all due to limited memory which seems excessively used when monitored using vmstat. We are unable to solve the predicament and any help will be gratefully recieved.

[Pete Randall]

I wouldn't think that this:
"/usr/lib/dld.sl: Invalid version for shared library: /usr/lib/libc.1
/usr/lib/dld.sl: Exec format error"
would have anything to do with how much memory is available. To prove or disprove that memory is the culprit, try running the compile when the system is not so busy - over the weekend, maybe?


Pete

[Adam J Markiewicz]

Hi

'which ld' -just to be sure
I guess it's '/usr/bin/ld'

chatr /usr/bin/ld

What does it say?

Good luck
Adam

PS: 'strings core' is very fuzzy. It can lead you to wrong conclusions.

[Eugeny Brychkov]

System coredumping process if it can not execute process anymore: invalid instruction, invalid memory access, can not load library to run etc.
In your case I believe something wrong is with dld.sl library. Check if it's not corrupt, has correct file size
Eugeny

[Eugeny Brychkov]

Sorry, not with dld.sl but with libc.1
Eugeny

[Des_2]

Pete: This is the only process running (besides system processes)

Adam: indeed it is /usr/bin/ld. chatr gives /usr/bin/ld:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
internal name:
ld
shared library list:
dynamic /usr/lib/libc.1
shared library binding:
deferred

Eugeny: How can i tell if /usr/lib/libc.1 is corrupt and what file size should it be on 10.10?

[Adam J Markiewicz]

Hi

I've tested in on 10.20 - the same result as yours.

Now try the same trick further:

chatr /usr/lib/libc.1

Good luck
Adam

[Steven E. Protter]

How about some core dump analysis. You might need a patch or something.

Attaching a cheatsheet.

SEP

[Des_2]

chatr /usr/lib/lib.1 gives

/usr/lib/libc.1:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
internal name:
libc.1
shared library list:
dynamic /usr/lib/libdld.1

[Adam J Markiewicz]

No luck. :(

You could chatr /usr/lib/libdld.1
I have an empty list here.

Also try 'what' and 'file' on this three.

Thats strange, as it looks like ld attaches only libc.1. Then libc.1 attaches libdld.1. And libdld.1 at startup refuses to work with this libc.1.

But this scenario should be equal for every program that uses libc. Or I'm missing something here.

[Des_2]

Adam, what is chatr supposed to be telling me - im afraid i have little knowledge of this command.

chatr /usr/lib/libdld.1 gives
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
internal name:
libdld.1


what /usr/lib/libdld.1 gives
92453-07 dld dld libdld.sl A.10.44 950920

what /usr/lib/libc.1 gives
PATCH/10_10 PHCO_16722 $Revision: 76.162.1.14.1.75 $

what /usr/bin/ld gives
92453-07 linker linker ld A.10.44 950920

file /usr/lib/libdld.1 gives
s800 shared library -not stripped

file /usr/lib/libc.1 gives
s800 shared library -not stripped

file /usr/bin/ld gives
s800 shared executable dynamically linked


PS: Points will be allocated later...

[Adam J Markiewicz]

Hi

'chatr' is used to check (or even change) the specific attributes. One of them is the list of shared libraries that are required. What I wanted to chech (and confirmed) is that it looks like on HP 10.20 I use.

You can see that:
ld requires /usr/lib/libc.1
libc.1 requires /usr/lib/libdld.1
/libdld.1 doesn't requre any extern shared library.

However it looks like the comment you have comes from libdld.1, complaining about libc.1 (notice the reverse order of dependence), so I was curios about the versions.
However - no luck, nothing suspicious. :(

'file' gave me exactly the same result in all cases.

$ what /usr/lib/libdld.1
/usr/lib/libdld.1:
92453-07 dld dld libdld.sl B.10.12 960426

$ what /usr/lib/libc.1
/usr/lib/libc.1:
PATCH/10.20:PHCO_13029 libc.1_ID@@/main/r10dav/libc_dav/libc_dav_cpe/7
/ux/core/libs/libc/shared_pa1/libc.1_ID
Oct 28 1997 16:44:16

$ what /usr/bin/ld
/usr/bin/ld:
92453-07 linker linker ld B.10.28 971016

I'm wondering about libc. Mayby the is some famous patch, you don't have?
However I'm only guessing, moreover I my results come from 10.20

I'm affraid I'm not able to help. :( Maybe someone with bigger brains can come to more ideas.

Good luck
Adam