[Openmcl-devel] startup 'terminal' window

[Phil Armitage]

2008/12/24 Gary Byers <gb at clozure.com>:

> You seem to be getting the same sort of error and are apparently getting
> it in some execution context where a lisp error can't be signaled (and
> it's just reported in the kernel debugger.)  Or something.

Thanks Gary. I'm not directly malloc'ing any memory but possibly some
layer of library code I'm using is. I'm trying to think of any unusual
things that the code may be doing:

1) LTK establishes a sub-process connection to the wish executable
(part of a Tcl/Tk installation) which I guess could be a suspect. I've
been careful to rebind all streams that I use (*standard-output*,
*standard-input*, *trace-output* and *error-output*) in my 'start-up'
function. Input is bound to a gray-stream so that I can capture things
like READ, etc. Also, LTK should be re-binding it's bi-directional
stream to the wish sub-process at start-up. So perhaps this isn't the
problem (it's certainly not directly memory related...).

2) I'm also using CL-FAD which I guess could ultimately be making
native platform calls via a specific compiler's filesystem APIs
(although allocating memory seems a stretch?). I haven't traced these
calls through for CCL so that's something else I can look into.

Probably the best option for me is to try to create a minimal example
which exhibits the problem rather than staring at a couple of thousand
lines and guessing!

> Is this a minor annoyance, an indication of a serious probkem, or something
> in between ?  It's imppssible to know without knowing what's trying to
> reference a stale/dead pointer and why.

As things stand I can deliver the application on 3 platforms so it's
not a huge problem for me. One or two of my OS X users have expressed
that they would like a CCL version of ABLE rather than SBCL or CLISP
so I am keen to resolve it but they realise this is open source and
they can only complain at me so much!

Thanks again for your help.

-- 
Phil Armitage
http://phil.nullable.eu/