Bug 000037
When Created: 11/22/1995 22:56:02
Against DJGPP version: 2.00.beta2
By whom: chrismac@midland.co.nz
Abstract: struct Spoint { int x, y, pz; } with pz =>lockup; else c++ comps/runs ok
In my global header file: (available on request)
struct Spoint { int x, y, pz; } with pz =>lockup displaying 3dBspline surface
else
struct Spoint { int x, y; } c++ v2b2 comps/runs ok, displaying 3dBspline surface
My 3D graphic engine has operated for some time without problems.
Adding in the pz member causes the program to enter what may be inf'loop ? I can
^c out under fsdb.
I have tried compiling with and without -O optimizations, no difference.
I have changed the struct name from Spoint to ScnPoint & back, no difference.
I have changed the member name pz to z, no difference.
I have tried removing -fsave-memoized, no difference.
Platform = Trident DX4, AMD CPU; under Win 3.11 dos box.
Q:It's as though the compiler corrupts memory meant to be set aside for structs.
This member is the last entry in my longish global header file.
My Makefile follows:
*******************************************************************************
CCAPPL = bspatch
CC=gcx
CFLAGS = -MD -O2 -c -g3 -I. -pedantic -fsave-memoized -m486
C2FLAGS = -MD -O2 -g3 -I. -pedantic -fsave-memoized -m486
LIBS = -lgrx20 -lgcc -lm -lpc
all: $(CCAPPL).exe
build:
$(MAKE) -W obj3d.cc
$(CCAPPL) $(CCAPPL).exe : $(CCAPPL).o obj3d.o objrndr.o userintf.o
$(CC) $(C2FLAGS) \
userintf.o $(CCAPPL).o objrndr.o obj3d.o $(LIBS) -o $(CCAPPL).exe
$(CCAPPL).o : $(CCAPPL).cc $(CCAPPL).h gbldecl.h objrndr.o obj3d.o
$(CC) $(CFLAGS) $(CCAPPL).cc
userintf.o : userintf.cc $(CCAPPL).o gbldecl.h
$(CC) $(CFLAGS) userintf.cc
objrndr.o : objrndr.h objrndr.cc obj3d.o
$(CC) $(CFLAGS) objrndr.cc
obj3d.o : obj3d.h obj3d.cc gbldecl.h
$(CC) $(CFLAGS) obj3d.cc
clean:
del *.o core
clobber:
del $(CCAPPL) *.o core
DEPS := $(*.d)
ifneq ($(DEPS),)
include $(DEPS)
endif
*******************************************************************************
Note added: 11/24/1995 20:12:14
By whom: chrismac@midland.co.nz
This bug appears to have been alleviated for now by removing redundant
#includes from user headers obj3d.h and objrndr.h .
The redundant includes were stdlib.h stdio.h strings.h & math.h; all
were put in gbldecl.h, but had not been removed from the other headers.
Now the struct pz member is compiling and running ok.
However, the 3d renderer has a few longish inline declared class methods, and
there does appear to be a related problem. One such method, in userintf.cc,
locks up the c++ compiler when not commented out. There is no indication of what
the problem could be; perhaps the compiler or preprocessor cannot handle too
many inline declarations and includes ? This is a compile time problem, unlike
the first problem which is runtime; but the compiler could be screwing up
memory layout for the first problem as a result of the same insufficient
capacity for inlines and includes ?
Chris
Workaround added: 11/30/1995 16:58:15
By whom: chrismac@midland.co.nz
My Trident machine has 8 Mb, which may be exhausted during compilation of large
modules with many inline declarations, such as my userintf.cc module was.
Having killed the windows dos box after compilation lock-up, I received a
no DPMI available message when starting another application; possibly
suggesting the compiler had exhausted my 8Mb and therefore locked-up.
My menu class had the long inline method declarations, with the display method
causing the compiler to lock up solid = no indication why.
I've factorised out of userintf.cc my menu class, putting it into separate
header & implementation modules menu.h/.cc .
Compilation of userintf.cc now completes, as does the menu module it uses,
and all appears to work ok so far.
Closed on 04/13/1999 09:00:31: Insufficient memory was causing this problem.
By whom: eliz@is.elta.co.il