The J line is verifying that special code for -/ . * is correct.
But both -/ . * and -"+/ . * should not go to jtatomic2, so it must be
failing on + or ? or $, I think. Look at jt->parserstackframe.sf
(=self) where it fails. It should match ds(CPLUS=0x23),
ds(CQUERY=0x11), or ds(CDOLLAR=0x43) which will tell you which verb is
running.
No, wait, I see: it must be running +, because it's running a dyad whose
x is an non-inplaceable integer (_100) and whose y is a 7x7 array of Xs.
That implicates the code for ? .
jtparsea doesn't look for anything but the type. In fact, it doesn't
even look at the type! The type is encoded into the low 5 bits of the
address of the A block for the word. jtparsea uses that code to index
an inverted parsing table.
Go into the code for ? on XNUMs and sprinkle audittstack around. Perhaps
an X is being stored into a recursive XNUM without incrementing the X's
usecount. That would cause a stack error on the next audit.
hhr
On 11/22/2023 5:23 PM, Raul Miller wrote:
So...
(1) I noticed that the version of problem.ijs I emailed was not the
version I had intended to send. The differences are inconsequential,
but I'm attaching the version which I had intended to send.
(2) Sprinkling p.c with lines which audittstack(jt), I can catch the
error on the line of this script immediately before the one which
previously I was catching it on. The offending line in p.c (jtparsea)
is:
y=(*actionfn)(jti,QCWORD(arg1),QCWORD(arg2),jt->parserstackframe.sf);
// set bit 0, and bit 1 if dyadic, if inplacing allowed by the verb
So... that's progress, though that's still rather ambiguous. Still, I
know it came from this line:
(-"+/ .* eqf -/ .*) m=: _100+?7 7$200x
And, running under a debugger, actionfn here is jtatomic2
Meanwhile, arg1 is:
{kchain = {k = 56, chain = 0x38, globalst = 0x38, locpath = 0x38},
flag = 0, mback = {
m = 93824992547648, back = 0x5555555a1340, jobpyx =
0x5555555a1340, zaploc = 0x5555555a1340,
aarg = 0x5555555a1340}, tproxy = {t = 4, proxychain = 0x4}, c = 1,
n = 1, r = 0 '\000',
filler = 0 '\000', h = 445, origin = 0, lock = 0, s = {-100}}
That is not an A with type XNUM - that looks like a broken X, with t=4
instead of t=2.
Also, for what it's worth, arg2 is:
{kchain = {k = 72, chain = 0x48, globalst = 0x48, locpath = 0x48},
flag = 64, mback = {
m = 93824992547688, back = 0x5555555a1368, jobpyx =
0x5555555a1368, zaploc = 0x5555555a1368,
aarg = 0x5555555a1368}, tproxy = {t = 64, proxychain = 0x40}, c =
-9223372036854775807, n = 49,
r = 2 '\002', filler = 0 '\000', h = 664, origin = 0, lock = 0, s = {7}}
Anyways, I'm looking for a little hint here.
Specifically, in jtparasea, where would I find the id of the verb
being handled by jtatomic2?
(Also, I'm back to wondering if something that jtparse depends on
might somehow be making a decision based on the ISGMP() macro, when
ISGMP() should really have been named ISGMPMEMORY() - it provides no
information about the J type of an array. But I haven't been able to
find any problem of that nature, and I've been looking for exactly
that problem. I'm not asking anyone to address this issue, it's just a
reflection of where I've been focussed.)
Anyways, any high level guidance on where the memorable bits are
stored in jtparsea would be great.
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
