Re: [palito-dev] last intro test core dumping

[Tom Barnes-Lawrence]

On Mon, Jun 30, 2003 at 08:02:39PM +1000, Michael Devey wrote:
> yeah I'm presently trying to get bit more of a handle on gdb

  I only worked out how to use GDB when I uncovered a copy of the Postscript
manual for it around christmas. Forget where I found it, but it enlightened
me enormously. Didn't have a clue before that.

>- because I'll be damned if I know what's going on.
 Well, I looked some more, and I realised that the "string" element in
cl->code->itrArray was actually part of a _union_, so the out of range
pointer I was seeing wasn't going to be the problem (I just assumed it
was because the flush code is confusing to me. So I had more of a look
around cpu_exec_code().

 It soon became obvious that actually it was getting upset from finding
an out-of-range instruction type. I should have realised that before.
So I'd suppose either the iteration in cpu_exec_code is continuing past
the bounds of the array into other data or whatever (because of the
ITR_RET instruction being missing), OR, when the array of instructions
is being filled in, some out-of-range value is being written.

 The latter possibility could likely be spotted more easily if the
structure definition in flush.h had:

struct structItr {
        enum InstructionID type;
        ...
};

rather than:

struct structItr {
        int type;
        ...
};

Apart from probably giving better compiler warnings, it'd make gdb
name the instructions used for the Itr structures, which is useful...

This would probably work better still if the definition of
enum InstructionID  were given earlier in the headers (as enums dont
depend on other types!). But perhaps there's a reason for all this-
as I've said, I don't much understand the flush code.

> nothing as satisfying as finding mistakes in barretts code:)

Hehe, I've never even heard from him yet! I heard he was back from
the Amazon already, but maybe that was a mistake, and he was eaten
by an anaconda?

 Tomble