It looks like something in audittstack is changing AFLAG(w) for one of
my X values which was created in my updated jtxplus(). (These look
like rank 1 LIT values, usually with a shape significantly smaller
than AN(w) -- sometimes negative, though not in this example.)
$1 = {kchain = {k = 64, chain = 0x40, globalst = 0x40, locpath =
0x40}, flag = 8589934592, mback = {m = 93824992548456,
back = 0x5555555a1668, jobpyx = 0x5555555a1668, zaploc =
0x5555555a1668, aarg = 0x5555555a1668}, tproxy = {t = 2,
proxychain = 0x2}, c = 1, n = 16, r = 1 '\001', filler = 0 '\000',
h = 354, origin = 0, lock = 0, s = {1}}
Specifically, it changes from 0 to 2^33 (on intel 64 bit) between two
successive calls to audittstack with no memory allocations nor frees
between them (one in plusXX immediately before the call to jtxplus and
the other on the first line of jtxplus). Apparently 2^33 represents
two deletes and 0 represents 0 deletes, while AC(x) is 1, in both
cases.
This suggests, in turn, that I have violated some assumption required
by the memory management system, though I'm not sure what that would
be. I'm using more-or-less stock GA to allocate the memory, and I
don't know where to look to isolate this kind of problem.
I guess I do have tactics to eventually isolate this kind of thing.
But, it's slow going. So, I'm leaving this note here in case it
reminds anyone of a plausibly relevant issue.
Thanks,
--
Raul
On Mon, Nov 27, 2023 at 11:06 PM Raul Miller <[email protected]> wrote:
>
> Here's what my stack looks like at the point of failure:
>
> #0 0x00007ffff293a2ae in auditsimdelete (jt=0x7ffff1438200,
> w=0x55555586e240) at ../../../../jsrc/m.c:553
> #1 0x00007ffff2939b14 in audittstack (jt=0x7ffff1438200) at
> ../../../../jsrc/m.c:648
> #2 0x00007ffff2e753e3 in jtxplus (jt=0x7ffff1438200,
> a=0x555555651240, w=0x555555651060) at ../../../../jsrc/vx.c:60
> #3 0x00007ffff2e7c2b6 in plusXX (n=-50, m=1, x=0x555555768940,
> y=0x5555556d17a8, z=0x5555556cfda0, jt=0x7ffff1438200)
> at ../../../../jsrc/vx.c:368
> #4 0x00007ffff2a0538a in jtva2 (jt=0x7ffff1438200, a=0x555555768900,
> w=0x5555556d1600, self=0x7ffff3a28580 <primtab+4480>,
> allranks=131072) at ../../../../jsrc/va2.c:749
> #5 0x00007ffff2a01ffa in jtatomic2 (jt=0x7ffff1438200,
> a=0x555555769080, w=0x5555556d1600, self=0x7ffff3a28580
> <primtab+4480>)
> at ../../../../jsrc/va2.c:1276
> #6 0x00007ffff2944b6c in jtparsea (jt=0x7ffff1438200,
> queue=0x55555571eda8, nwds=21) at ../../../../jsrc/p.c:785
> #7 0x00007ffff2943314 in jtparse (jt=0x7ffff1438200,
> w=0x55555571ed00) at ../../../../jsrc/p.c:290
> #8 0x00007ffff2951c95 in jtimmex (jt=0x7ffff1438200,
> w=0x55555571ed00) at ../../../../jsrc/px.c:54
>
> The line number for plusXX in vx.c will be one greater than the line
> number in the gmp-redo-messy branch, because I have added a line
> immediately before it:
>
> 366 {if(MEMAUDIT&2)audittstack(jt);}
> 367 void *previous= *z;
> 368 *z++= jtxplus(jt,(u),(v));
> 369 {if(MEMAUDIT&2)audittstack(jt);}
>
> The value of previous (and of *z) is 0. So, my thought in adding that
> line was useless, because the error happens before *z gets updated and
> before z gets updated.
>
> As best as I understand it, the only difference between line 366 here
> and the first line of jtxplus is the creation of a new stack frame for
> the jtxplus invocation.
>
> (And, I'm having difficulty reasoning about how that could cause
> audittstack to fail...)
>
> --
> Raul
>
> On Mon, Nov 27, 2023 at 9:44 PM Henry Rich <[email protected]> wrote:
> >
> > I think you're telling me to check out the gmp-redo-messy branch. Then
> > what do I look at? What is the failing line?
> >
> > hhr
> >
> > On 11/27/2023 8:17 PM, Raul Miller wrote:
> > > Ok.
> > >
> > > I've eliminated jmpn_com as a requirement (though not from the header
> > > file, you'll have to comment that out yourself), and pushed
> > > gmp-redo-messy with my jacked up instance of the code.
> > >
> > > Note that the rest of the code base is slightly out of date, as I've
> > > frozen the code base while trying to isolate this problem.
> > >
> > > FYI,
> > >
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
