Xref: utzoo comp.sys.att:2656 comp.unix.wizards:6752
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!aurora!eos!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Signal: EMT instruction
Message-ID: <7380@brl-smoke.ARPA>
Date: 29 Feb 88 01:17:05 GMT
References: <278@mancol.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17
Keywords: signals, EMT, sscanf

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.