Brian.Chan@bbs.acs.unc.edu (Brian Chan) (05/10/91)
(PART II to my quest on 3b2):
I kept getting a SIGEMT error. According to Rochkind's excellent
"Adv. Unix Programming" book: EMT means emulator trap instruction,
Sent when an implementaion-dependent hardware fault occurs.
"Extremely _rare_".
Alignment problem? I then rearranged all my structs in the header
files from small to large. It helps somewhat but it would core dump
again as soon as I added a few lines of code.
Finally I decided just stop what I was doing and wrote some simple
test program on the 3b2 and see what "it" will do.
Boy was I surprised.
Please look at the following program and tell me whether you see any
bugs in it.
/* test1.c */
#include <stdio.h>
#include <string.h>
void main(argc, argv)
int argc;
char **argv;
{
char msg1[32];
char msg2[64];
#ifdef DEBUG
printf("exe: main()\n\n");
#endif
bzero(msg1, 32);
strcpy(msg1, "this is ");
printf("%d ", strlen(msg1));
strcat(msg1, "a test of ");
printf("msg1 -> %s len->%d\n", msg1, strlen(msg1));
bzero(msg2, 31);
strcpy(msg2, "hey this is another test. this is ");
strcat(msg2, "a test of ");
strcat(msg2, "stupidity!\n");
printf("msg2 -> %s len->%d\n", msg2, strlen(msg2));
exit(0);
}
/* end test1.c */
The Makefile:
INCLDIR=/usr/local/include
CC = cc -O -DDEBUG -DSYSV
LINT = lint
OBJ= $(OUT).o
LFLAGS = -lnet -lnsl_s
.SUFFIXES: .exe .c
T_SRCS = test1.c
T_OUT = out
T_OBJS = $(T_SRCS:.c=.o)
$(T_OUT):: $(T_OBJS)
$(CC) -o $(T_OUT) $(T_OBJS) \
$(CFLAGS) $(LIBS) $(LFLAGS)
/* end Makefile */
It is a simple propram with some string processing. The result:
with _identical_ code and make file, the executable (after a fresh
make) will work sometimes
and sometimes core dump. When it works, adding some random
character(s) in the printf will break it and so forth. Weird!
The linking option (-lnet .. ) is for used with bzero(). (I also
tired my version of bzero but the core dump didn't go away.)
Using sdb, it points to the first statement printf(). Sometimes it
will core dump on strcat(). I also tried replacing printf() with
puts(). Didn't help, it still core dump at the same place.
I showed the test code and the compling-edit-cycle to my boss (a
competent C programmer) and he also was "amazed" this "interesting"
pheonomenon. (I didn't think he believed me at first.
Now he does.)
Can you help me to explain why the test code won't work reliably on
the 3b2? Is that something wrong with our 3b2 and the PLC? If I
can't even get this small test program to work reliably, I can kiss
my Sun port goodbye.
The 3b2 is a model 400 w/24 MRAM + 128 ports of FXM. The compiler
is a stock ATT Portable Compiler dated May 26 1987 with 30064 bytes.
cpp is 40k.
We received the "box" (new) last November.
(As a comparsion: the cc is 98K and the cpp is 82k on the Sun.)
On a second note, I still have not found anyone who has successfully
ported gcc or gdb to the 3b2. <Sigh.>
I redid the emacs port using the stock machine files for 3b2s. I added
one struct winsize in the sysdep.c. The makefile works and complies
fine after that. The binary works but the frequent core dump does
go away. Specifically id core dump at fatal_error_signal with sig fault.
Any ideas? (My gut feeling tells me there's something wrong with this
box.)
Your assistance is _greatly_ appreciated,
Brian.
Stuttgart, FRG.
--
The opinions expressed are not necessarily those of the University of
North Carolina at Chapel Hill, the Campus Office for Information
Technology, or the Experimental Bulletin Board Service.
internet: bbs.oit.unc.edu or 128.109.157.30rwhite@jagat.uucp (Robert White) (05/13/91)
In article <3717@beguine.UUCP> Brian.Chan@bbs.acs.unc.edu (Brian Chan) writes: > [Test program and makefile deleted] I'll have to try this one at work. Our senior progject team uses the 3B2/622 every month and have not problems with strings. As a first guess I would suggest you recompile the program without the libraries you spesified and put a #define of "bzero()" to make it call "memset()" My first-blush guess at your problem is that you are having a library colision. >I redid the emacs port using the stock machine files for 3b2s. I added >one struct winsize in the sysdep.c. The makefile works and complies >fine after that. The binary works but the frequent core dump does >go away. Specifically id core dump at fatal_error_signal with sig fault. >Any ideas? (My gut feeling tells me there's something wrong with this >box.) Putting Emacs on the 3B2 was really easy for me (ver 18.55) and it *does not* include putting *in* a winsize structure. The basic problem with 18.55 for use on the 3B2 (and with 3.2.1 on any AT&T offical release) is in the #ifdefs. There is a ioctl command named something like TIOGWINSIZE (or somehting it's been a year and a half or so...) which is used to detect for the presence of the entire winsize structure and behavior. The fix is to remove the #include that is "not found" and that the inline comments say is ok to remove, and at a point just above the ifdefs that suround it to #undefine TIOGWINSIZE (and on some implementations the TIOSWINSIZE symetric constant). The system header files have these, and a few other #defines, commented on as "purely for compatibility reasons" which generally translates as "no operation except for a it-worked return call" in human language. You are getting these core dumps because you have defined a structure and are perfroming calculations in the code baseid on the values that it contiains but the implementation the iocts are no-ops and the structure will contain random garbage at all times. Undefining the constants removes all the (unnecessary) code reguarding this (unnecessary on the 3B2) functionality. Worked fine for me and has been working without a crash for about a year. -- Robert C. White Jr. | I have moved my news reading activities rwhite@jagat <Home | not directly related to my job off of my rwhite@nusdecs <Work | employers machine. Please use "jagat" "Like most endevors, life is seriously over-advertised and under-funded"