bowman@reed.UUCP (Eric Bowman) (03/29/91)
Does anyone have any suggestions for what might cause a System Error 12?
IMII says it's an "Unimplemented Core Routine: An unimplemented trap
number was encounted."
It only happens inside a printing loop, on an app run over a network,
on a Mac Plus. Everything works fine on a Mac II, heap scrambling or no.
It's compiled for a 68000; written in MPW C++, and compiled using C 3.2b1
(optimizer on -- might this be the problem?)
Any suggestions would be greatly appreciated.
Thanks muchly,
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
BoBo Ready, Willing, & Abelian
bowman@reed.{edu,bitnet,uucp}
"I think that there is a moral to this story, namely that it is more important
to have beauty in one's equations than to have them fit experiment." - DiracJim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) (04/01/91)
Eric Bowman writes in a message to All EB> Does anyone have any suggestions for what might cause a System EB> Error 12? IMII says it's an "Unimplemented Core Routine: An unimplemented EB> trap number was encounted." EB> It only happens inside a printing loop, on an app run over a EB> network, on a Mac Plus. Everything works fine on a Mac II, heap EB> scrambling or no. It's compiled for a 68000; written in MPW C++, EB> and compiled using C 3.2b1 (optimizer on -- might this be the EB> problem?) EB> Any suggestions would be greatly appreciated. I don't profess expertise but could you be calling a trap that is not provided on a Plus, like a Color QuickDraw routine? Compiling for a 68000 only means you won't use FPU instructions, etc., not that you won't call a ROM routine which doesn't exist on the target. You don't get a compile or link error because you have the correct interface files and libraries.
n67786@cc.tut.fi (Tero Nieminen) (04/02/91)
In article <670554754.1@mmug.fidonet.org> Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) writes:
Eric Bowman writes in a message to All
EB> Does anyone have any suggestions for what might cause a System
EB> Error 12? IMII says it's an "Unimplemented Core Routine: An unimplemented
EB> trap number was encounted."
EB> It only happens inside a printing loop, on an app run over a
EB> network, on a Mac Plus. Everything works fine on a Mac II, heap
EB> scrambling or no. It's compiled for a 68000; written in MPW C++,
EB> and compiled using C 3.2b1 (optimizer on -- might this be the
EB> problem?)
EB> Any suggestions would be greatly appreciated.
I don't profess expertise but could you be calling a trap that is not
provided on a Plus, like a Color QuickDraw routine? Compiling for a
68000 only means you won't use FPU instructions, etc., not that you
won't call a ROM routine which doesn't exist on the target. You don't
get a compile or link error because you have the correct interface files
and libraries.
More probably it's just some random data that the OS interprets as a
nonexisting trap. It's gone haywire and riunning wild in the memory and
this just happened to be the spot where OS begun doubting what's going
on.
--
Tero Nieminen Tampere University of Technology
n67786@cc.tut.fi Tampere, Finland, Europecaptkidd@athena.mit.edu (Ivan Cavero Belaunde) (04/05/91)
In article <670554754.1@mmug.fidonet.org> Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) writes: >>Eric Bowman writes in a message to All >EB> Does anyone have any suggestions for what might cause a System >EB> Error 12? IMII says it's an "Unimplemented Core Routine: An unimplemented >EB> trap number was encounted." >EB> It only happens inside a printing loop, on an app run over a >EB> network, on a Mac Plus. Everything works fine on a Mac II, heap >EB> scrambling or no. It's compiled for a 68000; written in MPW C++, >EB> and compiled using C 3.2b1 (optimizer on -- might this be the >EB> problem?) >EB> Any suggestions would be greatly appreciated. #undef LURK A fairly common reason for SysErr 12 is, I've found, running a pgm with a Debugger() or DebugStr() statement in it without a debugger installed. It's a little less likely than other suggestions that I've seen out here (Mac II specific code, for instance) but possible. Either way, though, the obvious suggestion is to install a debugger in the Plus. Then if it is a Debugger() statement it will break into the monitor, and if it's not it will break anyway and you'll be able to look at the trap # and look it up. Hope this helps. As an aside, I wanted to thank andy@treehouse.UUCP for his helpful response on navigating the extent B-Tree and stuff. I tried mailing, but it bounced. #define LURK -Ivan
bowman@reed.UUCP (Eric Bowman) (04/06/91)
In article <1991Apr5.011516.23646@athena.mit.edu> captkidd@athena.mit.edu (Ivan Cavero Belaunde) writes: >A fairly common reason for SysErr 12 is, I've found, running a pgm with a >Debugger() or DebugStr() statement in it without a debugger installed. It's >a little less likely than other suggestions that I've seen out here (Mac II >specific code, for instance) but possible. Either way, though, the obvious >suggestion is to install a debugger in the Plus. Then if it is a Debugger() >statement it will break into the monitor, and if it's not it will break anyway >and you'll be able to look at the trap # and look it up. Hope this helps. This was the problem...which raises another question?: Why doesn't a _Debugger trap bring up the funky old debugger in rom? later, -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= BoBo Ready, Willing, & Abelian bowman@reed.{edu,bitnet,uucp} "I think that there is a moral to this story, namely that it is more important to have beauty in one's equations than to have them fit experiment." - Dirac
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (04/09/91)
In article <16299@reed.UUCP> bowman@reed.UUCP (Eric Bowman) writes: >This was the problem...which raises another question?: Why doesn't a _Debugger >trap bring up the funky old debugger in rom? In the Mac you break into the debugger in one of a number of ways. You press the NMI switch, you cause a system error, or you issue a debugger trap. The NMI switch is tied (via the NMI vector) to the ROM Debugger. The _Debugger trap, however, does not exist until it is installed by Macsbug/TMON/Whatever using SetTrapAddress. When it's installed, the debugger will also reroute the NMI vector to itself so that pressing the switch will take you to itself instead of giving you the '>' prompt (shades of MessyDOS ;-). I pressume that the System Error Handler checks for the existence of the Debugger trap before giving you the bomb alert and breaks into it. -Ivan Cavero Belaunde Visualist Digital Video Applications Corp. (DiVA) Internet: captkidd@ATHENA.MIT.EDU