I traced and got this simple sentence to crash.
_1x + 1x
123x
I suspect when result in plusXX is 0, it frees memory but forgets some
housekeeping flags. So the block is doubly freed in the next gc.
On Fri, Dec 1, 2023 at 10:07 Raul Miller <rauldmil...@gmail.com> wrote:
> This seems to be the "source" of the audittstack "too many deletes" error:
>
> (gdb) p ttop
> $5 = (A *) 0x5555555a1660
> (gdb) p *ttop
> $6 = (A) 0x55555586e240
> (gdb) p ttop[1]
> $7 = (A) 0x55555586e240
> (gdb) p ttop[0]
> $8 = (A) 0x55555586e240
>
> The same entry is on the stack twice (though AC(w) is 1).
>
> But this doesn't come after a direct update of "ttop" - it seems like
> a failure to properly clean up after the previous audittstack.
>
> So... how do I audit audittstack?
>
> Thanks,
>
> --
> Raul
>
> On Wed, Nov 29, 2023 at 7:50 PM Raul Miller <rauldmil...@gmail.com> wrote:
> >
> > 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 <rauldmil...@gmail.com>
> 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 <henryhr...@gmail.com>
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
