Hi everybody!
At last I have also runned into one of those nasty things which this
list almost everytime solves in an incredible short time.
First some basic data about our environment: (well, maybe I provide to much)
AlphaServer 1000A 4/266
Digital UNIX V3.2G (Rev. 62)
physical memory = 576.00 megabytes.
Total swap allocation:
Allocated space: 265097 pages (2071MB)
Reserved space: 105541 pages ( 39%)
In-use space: 77616 pages ( 29%)
Available space: 159556 pages ( 60%)
sysconfig -q proc:max-proc-per-user = 150
max-threads-per-user = 256
per-proc-stack-size = 2097152
max-per-proc-stack-size = 33554432
per-proc-data-size = 134217728
max-per-proc-data-size = 1073741824
max-per-proc-address-space = 1073741824
per-proc-address-space = 1073741824
autonice = 0
open-max-soft = 4096
open-max-hard = 4096
ncallout = 506
ncallout_alloc_size = 8192
round-robin-switch-rate = 0
round_robin_switch_rate = 0
sched-min-idle = 0
sched_min_idle = 0
give-boost = 1
give_boost = 1
sysconfig -q vm
ubc-minpercent = 10
ubc-maxpercent = 100
ubc-borrowpercent = 20
ubc-maxdirtywrites = 5
ubc-nfsloopback = 0
vm-max-wrpgio-kluster = 32768
vm-max-rdpgio-kluster = 16384
vm-cowfaults = 4
vm-mapentries = 200
vm-maxvas = 1073741824
vm-maxwire = 16777216
vm-heappercent = 7
vm-vpagemax = 16384
vm-segmentation = 1
vm-ubcpagesteal = 24
vm-ubcdirtypercent = 10
vm-ubcseqstartpercent = 50
vm-ubcseqpercent = 10
vm-csubmapsize = 1048576
vm-ubcbuffers = 256
vm-syncswapbuffers = 128
vm-asyncswapbuffers = 4
vm-clustermap = 1048576
vm-clustersize = 65536
vm-zone_size = 0
vm-kentry_zone_size = 16777216
vm-syswiredpercent = 80
vm-inswappedmin = 1
vm-page-free-target = 128
vm-page-free-min = 20
vm-page-free-reserved = 10
vm-page-free-optimal = 74
vm-page-prewrite-target = 256
dump-user-pte-pages = 0
kernel-stack-guard-pages = 1
vm-min-kernel-address = 18446744071562067968
contig-malloc-percent = 20
vm-aggressive-swap = 0
new-wire-method = 0
vm-segment-cache-max = 50
vm-nowait-memalloc = 0
gh-chunks = 0
gh-min-seg-size = 8388608
gh-fail-if-no-mem = 1
vm-page-lock-count = 0
enable-madvise-dontneed = 0
And now our problem. The following command causes ld to core dump:
(yes, it is a little bit redicolous long command but please, never mind)
cc -migrate -g -o bin/cen_eu /usr/ingres/lib/abfmain.obj src/cen_eu.o
-Llib/ -L/proj/tds/pub27/lib -L/proj/ss/il7/lib -L/install/ingres/sqr
-L/usr/ingres/lib /proj/ss/il7/lib/libstd.a /proj/ss/il7/lib/libbe.a
-lcen -lim -lik -lex -lup -lha -lexp /proj/stod/el/lib/libfo.a
/proj/stod/el/lib/libgr.a /proj/stod/el/lib/libta.a
/proj/stod/il26/lib/libtu.a -lim -lup -lex -lexp
/proj/ss/il7/lib/libstd.a /proj/ss/il7/lib/libra.a
-lim /proj/stod/el/lib/libta.a /proj/stod/el/lib/libtu.a
/proj/stod/el/lib/libfo.a /proj/stod/el/lib/libpn.a -lik -lha -lstd
-lra -lbe -lhlp -lssdef -ltp -ltdk -lsqr -ldnet_sub -lbsd
-lingres -lm -lc
and we get the following output:
ld_mmap: Could not malloc 311968. bytes, for
/proj/stod/el/lib/libtu.a(tu31801r00.o), didnt attempt to mmap
ld_mmap: Could not malloc 311968. bytes, for
/proj/stod/el/lib/libtu.a(tu31801r00.o), didnt attempt to mmap
file file_offset / flen
-- pg bndry file offst --> last file offst mmapd
mmap usage info not available; max of 160. slots
Fatal error in: /usr/lib/cmplrs/cc/ld IOT/Abort trap - core dumped
*** Exit 6
Stop.
We are problably out of some kind of limit. But wich? Any ideas? please
let me know. I'll summarize.
Many thanks from the north part of Sweden!
====================================================================
Ingvar Larsson, Swedish Customs ingvar.g.larsson_at_tullverket.se
Received on Tue Apr 15 1997 - 17:32:24 NZST