So... near as I can tell, the problem occurs inside plusXX which
resides between jtva2 and jtxplus.
Specifically, an audittstack in jtva2 like this:
{if(MEMAUDIT&2)audittstack(jt);}
{I lrc=((AHDR2FN*)aadocv->f)(n,m,av,wv,zv,jt); // run one
section. Result of 0 means error
{if(MEMAUDIT&2)audittstack(jt);}
and in jtplusx like this:
XF2(jtxplus){ // a+w
{if(MEMAUDIT&2)audittstack(jt);}
gives me a segfault with a stack trace on that first line of jtxplus,
with plusXX between jtva2 and jtxplus, and of course with the above
lrc= line on the stack for jtva2 (but only after the 150 seconds of
scripting to trigger the problem).
--
Raul
On Wed, Nov 22, 2023 at 7:44 PM Raul Miller <rauldmil...@gmail.com> wrote:
>
> Ah, yes, r=0, not 1. So that is an A of type INT, and not a broken X
> like I had suggested.
>
> I'll check out the ? implementation like you suggested.
>
> (And, you were exactly right about what mpn_com does.)
>
> Thanks,
>
> --
> Raul
>
> On Wed, Nov 22, 2023 at 5:49 PM Henry Rich <henryhr...@gmail.com> wrote:
> >
> > 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
