Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!olivea!tardis!tymix!uunet!mdisea!jackb
From: jackb@MDI.COM (Jack Brindle)
Newsgroups: comp.sys.mac.apps
Subject: Re: Versaterm & Mathematica
Keywords: Versaterm, Mathematica
Message-ID: <1991May9.235749.4208@MDI.COM>
Date: 9 May 91 23:57:49 GMT
References: <1991May8.225511.126@midway.uchicago.edu> <1991May9.181042.13564@src.honeywell.com> <1991May9.201312.17709@midway.uchicago.edu>
Sender: news@MDI.COM
Distribution: na
Organization: Motorola, Mobile Data Division - Seattle, WA
Lines: 24

In article <1991May9.201312.17709@midway.uchicago.edu> langer@gibbs.UUCP (Steve Langer) writes:
>What can Versaterm be doing to make Mathematica crash *after* Versaterm
>quits? Does it confuse the modem port in some way, and Mathematica
>has a bug that only lets it start if the modem port is not confused?
>I'm not using a remote Mathematica kernel, so it shouldn't care
>about the port, right? The principle of cause and effect seems to say
>that Versaterm is at fault, not Mathematica.
>

Come now. There's lots. Versaterm may be patching system calls, then
unpatching them when it leaves. One of the tricks we use to speed things
up is to get a trap address, and call it directly. When Versaterm removed
the patch, it might leave the direct address incorrect (it was the address
of the patch...). Mathematica calls the old address, and crashes. There are
quite a few similar scenerios that could also cause crashes (changes to
common globals, i.e. not those that MultiFinder swaps out, etc.). The
Mathematica developers could tell you quickly if they do  anything that
patching would affect, like trap dereferencing. Some programs (mostly older
ones, pre-MultiFinder) leave trails behind that the Finder would clean up.
With MultiFinder, this may not happen, and thus a crash may occur.
So, who's fault is it? Neither, or both. Either way, you're not happy...

Jack Brindle
ham radio: wa4fib/7