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 <[email protected]> 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 <[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
