samperi@mancol.UUCP (Dominick Samperi) (02/28/88)
Can someone explain what an EMT instruction signal means? I'm getting
this signal when I try to run a program on a 3b2/400. The program runs
fine on other machines. The signal occurs in a sscanf() call, so sdb
does not resolve the problem. Thanks.
--
Dominick Samperi, Manhattan College, NYC
manhat!samperi@NYU.EDU ihnp4!rutgers!nyu.edu!manhat!samperi
philabs!cmcl2!manhat!samperi ihnp4!rutgers!hombre!samperi
(^ that's an ell) uunet!swlabs!mancol!samperigwyn@brl-smoke.ARPA (Doug Gwyn ) (02/29/88)
In article <278@mancol.UUCP> samperi@mancol.UUCP (Dominick Samperi) writes: >Can someone explain what an EMT instruction signal means? I'm getting >this signal when I try to run a program on a 3b2/400. The program runs >fine on other machines. The signal occurs in a sscanf() call, so sdb >does not resolve the problem. Thanks. Sdb is just a tool; it doesn't resolve problems. Since you didn't tell us enough about what sdb turned up, how can we help you? My guess is that you forgot that sscanf() needs pointers to the variables to receive the data, not the contents of the variables. EMT was a PDP-11 instruction; SIGEMT should not turn up under normal circumstances. I suppose it is possible that you built your 3B2 program for hardware containing the MAU but are trying to run it on a 3B2 without a MAU. Otherwise, you've probably just corrupted your process's instructions somehow, probably by overwriting them via bad use of pointers.
friedl@vsi.UUCP (Stephen J. Friedl) (02/29/88)
In article <278@mancol.UUCP>, samperi@mancol.UUCP (Dominick Samperi) writes: > Can someone explain what an EMT instruction signal means? I'm getting > this signal when I try to run a program on a 3b2/400. The program runs > fine on other machines. The signal occurs in a sscanf() call, so sdb > does not resolve the problem. Thanks. The problem is undoubtedly either a mismatch in the type of the % specification and the receiving variable or you are forget- ting to put & before the variable being passed (not applicable for arrays). For example: { short foo; sscanf(buf, "%d", &foo); /* fault here! */ You will probably get a hundred responses like the above but the EMT question is what elicited this posting in the hopes that the following is of general interest. We've done some testing on the 3B2 to find out what kinds of programming errors yield which kinds of faults. Over the years I have observed that terms like "EMT Trap", "IOT Trap", "Segmenta- tion violation", and "Bus error" do not point as directly to the source of the problem as they perhaps used to. I think that "EMT" comes from "Emulator Trap" (not sure, can't find my VAX or PDP-11 reference manuals) but that term doesn't mean anything on the WE32100. The following is the output of some testing software we have written to see what is doing on inside various machines: Fault Test Divide-by-zero: Integer signal 8; Floating Exception (!) Divide-by-zero: Floating signal 4; Illegal Instruction Reference at NULL (no signal) Reference at Odd Address signal 7; EMT Trap Reference beyond .data section signal 11; Segmentation Violation Reference beyond base of stack signal 11; Segmentation Violation Store at NULL signal 10; Bus Error Store at Odd Address signal 7; EMT Trap Store beyond .data section signal 11; Segmentation Violation Store beyond base of stack signal 11; Segmentation Violation 3B Privileged Register Access signal 4; Illegal Instruction 3B Privilged Opcode signal 4; Illegal Instruction 3B Reserved Opcode signal 4; Illegal Instruction 3B BPT Instruction signal 5; Trap 3B Illegal Opcode signal 4; Illegal Instruction 3B Invalid Descriptor signal 4; Illegal Instruction I hope this is helpful. Reporting of bugs in the above table is encouraged. Steve -- Life : Stephen J. Friedl @ V-Systems, Inc/Santa Ana, CA *Hi Mom* CSNet: friedl%vsi.uucp@kent.edu ARPA: friedl%vsi.uucp@uunet.uu.net uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl