That sounds very plausible. Thanks.
Previously I had a special value that I always used for 0x. It makes
sense to be using it here.
I'll try that and see if it clears things up.
Thanks again,
--
Raul
On Sat, Dec 2, 2023 at 12:36 AM bill lam <bbill....@gmail.com> wrote:
>
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
