| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
I have an executable (C and Fortran code) which fails to execute, with the following message: exception system: exiting due to internal error: out of memory trying to allocate exception system resources I had to use unlimit datasize to avoid a heap allocation failure in order to get this far. I have tried increasing maxdsiz (initially 1073741824) but it made no difference. Running from dbx reveals that the problem is apparently in the initialisation code (it doesn't reach main): ddors.reo.dec.com> dbx meshv dbx version 3.11.10 Type 'help' for help. (dbx) stop in main [2] stop in main (dbx) run exception system: exiting due to internal error: out of memory trying to allocate exception system resources Program terminated normally I'm using DUNIX V4.0A. Any suggestions?
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 8690.1 | QUARRY::neth | Craig Neth | Tue Feb 04 1997 08:55 | 5 | |
Can you point us at the object? Looking at the code, it looks like it might be a bad/corrupt object - the exception handling system is trying to malloc some memory for some internal data structures it uses. If the exception handling sections in the object were all screwed up one could imagine it doing something like this. | |||||
| 8690.2 | How did you build it? | WTFN::SCALES | Despair is appropriate and inevitable. | Tue Feb 04 1997 10:20 | 4 |
Giving us your full compile and link lines might be illuminating, too. Webb | |||||
| 8690.3 | apc013.reo.dec.com:/pub/meshv | RDGENG::READINGS_R | Richard Readings | Wed Feb 05 1997 03:08 | 14 |
Re .1 >Can you point us at the object? It's available by anonymous ftp from apc013.reo.dec.com:/pub/meshv Re .2 I'll request the compile and link lines from the customer. I only have the executable here. Thanks for the help Richard | |||||
| 8690.4 | Makefile with -taso | RDGENG::READINGS_R | Richard Readings | Mon Feb 10 1997 03:43 | 69 |
Re .2
The application is being linked with -taso. Could that be the problem?
---------------------------------------------------------------
This is the Makefile of the fortran sources
---------------------------------------------------------------
F77 = f77 -O -convert big_endian $(DEBUG) -c
OBJ_F = `cat ../../files/FortranAxp`
all:
make `cat ../../files/FortranAxp`
.f.o:
@echo ""
@echo "Compile $< with $(F77)"
@echo ""
@$(F77) $<
-----------------------------------------------------
This is the Makefile of the c sources
-----------------------------------------------------
OBJ_F=`cat ../../files/FortranMeshvAxp`
OBJ_C=bibX11c.o cb.o cb_visu.o cio.o control_mesh.o dialogue.o fsb.o image.o
info.o iso.o meshv.o pref.o region.o rot.o utils.o
ROOT = meshv
BINDIR = ../../../bin_axp/
SRCDIR = ../../src/$(ROOT)/
INCDIR = ../../src/include/
LIBX = -lMrm -lXm -lXt -lX11 -lm -lots -lfor -lUfor
CFLAG = $(DEBUG) -D_NO_PROTO -DNO_REGEX -DSTRINGS_ALIGNED -DSUN
$(DEBUGMODE)
CC = cc $(CFLAG) -I$(INCDIR) -O
F77 = f77 $(DEBUG)
LD = $(PURE) cc $(DEBUG)
UID = $(BINDIR)fm_$(ROOT).uid
OBJ = $(OBJ_F) $(OBJ_C)
BIN = $(BINDIR)$(ROOT)
BINS = $(BIN) $(UID)
all:$(BINS)
@echo ">>> All binaries ok"
$(OBJ_C):$(SRCDIR)$(*)
@echo ">>> cc [$(SRCDIR)$(@F:.o=.c) -> $@ ] $(DEBUG)
@$(CC) -c $(SRCDIR)$(@F:.o=.c)
$(BIN):$(OBJ_C)
@echo ">>> ld [ $(@F) -> $@ ]"
@$(LD) -taso -o $(@) $(OBJ) $(LIBX)
$(UID):$(SRCDIR)fm_$(ROOT).uis
@echo ">>> uil [fm_$(ROOT).uis -> $(UID) ]"
@/usr/bin/X11/uil $(SRCDIR)/fm_$(ROOT).uis -o $(UID)
| |||||
| 8690.5 | V4.0B, too | SAPEC3::WALLMEROTH | Mon Feb 10 1997 04:14 | 70 | |
Sorry, bad news. The "not wired" panic still occurs in V4.0B.
This time in happened during the database build phase, so we
don't reach the point, where we can tell whether database
informations got corrupted without leading to a panic. The
database is Adabas again. No news about Informix.
The worst thing in .0 is that you not always (should I say seldom)
get a panic, but the application continues with corrupted data !
Shouldn't we warn our customers ?
A few lines out of crash-data follow:
pmap_lw_unwire_new: pmap 0xfffffc000ea68600 pte 0xa5e200083309
panic (cpu 2): not wired
Begin Trace for machine_slot[paniccpu].cpu_panic_thread:
thread 0xfffffc003de61080 stopped at [stop_secondary_cpu:513 ,0xffff
fc00004f8988] Source not available
warning: Files compiled -g3: parameter values probably wrong
> 0 stop_secondary_cpu(do_lwc = 0x0) ["../../../../src/kernel/arch/al
pha/cpu.c":507, 0xfffffc00004f8984]
1 panic(s = 0xfffffc00006b4c88 = "event_timeout: panic request") ["
../../../../src/kernel/bsd/subr_prf.c":703, 0xfffffc000027b190]
2 event_timeout(func = 0xfffffc000027b3c0, arg = 0xfffffc0000738040
, timeout = 0x5) ["../../../../src/kernel/arch/alpha/cpu.c":1005, 0xff
fffc00004f9780]
3 xcpu_puts(s = 0xfffffc00006ef790, prfbufp = 0xfffffc0000738040) [
"../../../../src/kernel/bsd/subr_prf.c":844, 0xfffffc000027b424]
4 printf(va_alist = 0xfffffc000066a9d8) ["../../../../src/kernel/bs
d/subr_prf.c":379, 0xfffffc000027a820]
5 panic(s = 0xfffffc00006bbb90 = "not wired") ["../../../../src/ker
nel/bsd/subr_prf.c":753, 0xfffffc000027b2e8]
6 pmap_lw_unwire_new(map = 0xfffffc000ea68600, start = 0x1cc2000, b
itmap = 0xffffffffa905f590) ["../../../../src/kernel/arch/alpha/pmap.c
":6398, 0xfffffc000052619c]
7 lw_unwire_new(0xffffffffa905f848, 0xffffffffa905f838, 0x1cc4000,
0x1000, 0xfffffc0000494480) ["../../../../src/kernel/bsd/kern_mman.c":
3441, 0xfffffc00002665b8]
8 vm_map_pageable(0x1cc4000, 0x1000, 0xfffffc0000494480, 0x1, 0xfff
ffc00004944ac) ["../../../../src/kernel/vm/vm_map.c":1269, 0xfffffc000
04dd58c]
9 physio(0xfffffc0000654260, 0x0, 0xfffffc0000537310, 0xfffffc00005
42620, 0x10080d004) ["../../../../src/kernel/ufs/ufs_physio.c":327, 0x
fffffc00004944a8]
10 cdisk_read(uio = 0xffffffffa905f848) ["../../../../src/kernel/io/
cam/cam_disk.c":7916, 0xfffffc0000537fd0]
11 spec_read(0x11ffffbc0, 0x0, 0x0, 0xfffffc003cd97f00, 0xfffffc0000
80d004) ["../../../../src/kernel/vfs/spec_vnops.c":1870, 0xfffffc00004
a3c98]
12 msfsspec_read(vp = 0xfffffc003b65a200, uio = 0xffffffffa905f848,
ioflag = 0x5, cred = 0xfffffc003cd97f00) ["../../../../src/kernel/msfs
/osf/msfs_vnops.c":4422, 0xfffffc00003eb02c]
13 vn_read(0xfffffc0000289ee4, 0xffffffffa905f8e0, 0xffffffffa905f84
8, 0x0, 0xfffffc003d5ed980) ["../../../../src/kernel/vfs/vfs_vnops.c":
877, 0xfffffc00004c4d8c]
14 rwuio(0xfffffc00138ccca0, 0xfffffc003de61080, 0xfffffc00006d7f30,
0xfffffc00138cca80, 0xfffffc003d5ed980) ["../../../../src/kernel/bsd/
sys_generic.c":1217, 0xfffffc0000289f38]
15 read(0xfffffc0000001000, 0xffffffffa905f838, 0x573000, 0x10000000
0001, 0x0) ["../../../../src/kernel/bsd/sys_generic.c":1167, 0xfffffc0
000289e48]
16 syscall(0x1000, 0xfffffc00004fee44, 0x9e2b432f10bf1, 0x1205d099c,
0x3) ["../../../../src/kernel/arch/alpha/syscall_trap.c":540, 0xfffff
c0000507d80]
17 _Xsyscall(0x8, 0x3ff800d1818, 0x14008ada0, 0x3, 0x1cc2000) ["../.
./../../src/kernel/arch/alpha/locore.s":1209, 0xfffffc00004fde44]
End Trace for machine_slot[paniccpu].cpu_panic_thread:
| |||||
| 8690.6 | QUARRY::neth | Craig Neth | Mon Feb 10 1997 10:30 | 6 | |
Ummm, .5 looks like a reply to the wrong note... As far as .4 goes, mail was sent offline. The program has a huge data section and is running out of space for the heap. Some suggestions were made on how to rearrange the memory map to make things fit. | |||||
| 8690.7 | linked with -taso | RDGENG::READINGS_R | Richard Readings | Tue Feb 11 1997 02:55 | 11 |
Re .6 >As far as .4 goes, mail was sent offline. The program has a huge >data section and is running out of space for the heap. Some suggestions >were made on how to rearrange the memory map to make things fit. Thanks to Craig for the help. I should point out that the program was linked with -taso, which seems to be the cause of the problem, in case anyone else stumbles across this. Richard | |||||