Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!gatech!mcnc!beguine!bbs.acs.unc.edu
From: Brian.Chan@bbs.acs.unc.edu (Brian Chan)
Newsgroups: comp.sys.att
Subject: A weird 3b2 problem and SIGEMT (PART II) -LONG
Message-ID: <3717@beguine.UUCP>
Date: 10 May 91 15:51:38 GMT
Sender: usenet@beguine.UUCP
Organization: Extended Bulletin Board Service
Lines: 123

(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.30