Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!dog.ee.lbl.gov!nosc!crash!jagat!rwhite From: rwhite@jagat.uucp (Robert White) Newsgroups: comp.sys.att Subject: Re: A weird 3b2 problem and SIGEMT (PART II) -LONG Message-ID: <1991May12.204659.14599@jagat.uucp> Date: 12 May 91 20:46:59 GMT References: <3717@beguine.UUCP> Organization: My House (no organization to speak of) Lines: 49 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