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,
--
Raul
On Mon, Nov 27, 2023 at 10:22 AM Henry Rich <henryhr...@gmail.com> wrote:
>
> You're getting really close. If you have put audittstack between all
> the lines of jtxplus, the erroneous action will be the line before the
> failing audit. It won't be a wild store; it will be a store that messes
> up a usecount. The usual way to mess up the usecount is to forget to
> increment the usecount when storing an X address into a recursive XNUM.
> I can't tell here whether zv (debug line $17) is recursive. That info
> is carried in the AFLAGS field. For example, in line $11 flags is 64
> (=XNUM), indicating that w is recursive XNUM. If you check in all your
> stuff and give me a testcase I'll look along with you (if you don't give
> me a testcase I can still follow the source).
>
> Now, about va2 and loops. You will do us all a great favor if you copy
> the following into the JE source at whatever spot you think will do the
> most good. That could be va2.c, va.h, or elsewhere.
>
>
>
> Executing an atomic verb (a + b) has up to 2 implied loops depending on
> the ranks of a and b. These loops are executed inside each action
> routine (pointed to by adocv.f in jtva2). Each call to the action
> routine supplies the address of the inputs and result, and two loop
> counts m and n. jtva2 calculates m and n, meaning:
> n=1: single vector-to-vector operation of length m atoms
> n>1: m atom-to-vector operations with the x argument repeated n times.
> After each vector is finished the x argument advances to its next atom;
> the y argument advances throughout.
> n<1: m vector-to-atom operations with the y argument repeated ~n times.
> After each vector is finished the y argument advances to its next atom;
> the x argument advances throughout.
>
> Neither m nor n may be 0 or ~0.
>
> The operation returns 256 if no error, or an error code in the range
> [1,256).
>
> Executing an atomic verb with rank (a +"r b) invokes up to 2 more
> implied loops inside jtva2. These loops work through the outer cells of
> u"r, calling adocv.f as before to perform the operation on inner cells.
>
>
>
> hhr
>
> On 11/26/2023 11:58 PM, Raul Miller wrote:
> > So... I've expanded the definition of plusXX and put audittstacks
> > between each line. In other words, basically:
> >
> > I plusXX(I n, I m, X* x, X* y, X* z, JJ jt){
> > X u; X v;
> > if (n-1==0) {
> > I i= (I)(m)-1;
> > for (; i>=0; --i){
> > u= (*x++);
> > v= (*y++);
> > *z++= jtxplus(jt,(u),(v));
> > }
> > } else if (n-1<0){
> > I i= (I)(m)-1;
> > for (; i>=0; --i){
> > u= (*x++);
> > {
> > I i= -2-(I)(n);
> > for (; i>=0; --i){
> > v= (*y++);
> > *z++= jtxplus(jt,(u),(v)); // this update of *z is "the" problem
> > }
> > }
> > }
> > } else {
> > I i= (I)(m)-1;
> > for (; i>=0; --i){
> > v= (*y++);
> > {
> > I i= (I)(n)-1;
> > for (; i>=0; --i){
> > u= (*x++);
> > *z++= jtxplus(jt,(u),(v));
> > }
> > }
> > }
> > };
> > I rc= jt->jerr;
> > jt->jerr= 0;
> > return rc?rc:256;
> > }
> >
> > Unfortunately, I'm a bit lost here - I do not know what I am looking at.
> >
> > The line in jtva2 which called plusXX looks like this:
> >
> > #3 0x00007ffff29e7bec in jtva2 (jt=0x7ffff13e8200, a=0x555555768900,
> > w=0x5555556d1600,
> > self=0x7ffff3a28600 <primtab+4480>, allranks=131072) at
> > ../../../../jsrc/va2.c:749
> > 749 {I lrc=((AHDR2FN*)aadocv->f)(n,m,av,wv,zv,jt); //
> > run one section. Result of 0 means error
> >
> > n is -50
> > m is 1
> > av, wv and zv are pointers into memory somewhere.
> >
> > The call to jtva2 looked like this:
> >
> > #4 0x00007ffff29e45fb in jtatomic2 (jt=0x7ffff13e8200,
> > a=0x555555769080, w=0x5555556d1600,
> > self=0x7ffff3a28600 <primtab+4480>) at ../../../../jsrc/va2.c:1276
> > 1276 z=jtva2(jtinplace,a,w,self,(awr<<RANK2TX)+selfranks); //
> > execute the verb
> > (gdb) p *a
> > $10 = {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}}
> > (gdb) p *w
> > $11 = {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}}
> > (gdb) p self
> > $12 = (A) 0x7ffff3a28600 <primtab+4480>
> > (gdb) p *self
> > $13 = {kchain = {k = 56, chain = 0x38, globalst = 0x38, locpath =
> > 0x38}, flag = 134217728, mback = {m = 0, back = 0x0,
> > jobpyx = 0x0, zaploc = 0x0, aarg = 0x0}, tproxy = {t = 134217728,
> > proxychain = 0x8000000},
> > c = 4611686018427387904, n = 0, r = 0 '\000', filler = 0 '\000', h =
> > 0, origin = 0, lock = 0, s = {0}}
> > (gdb) p awr
> > $14 = 2
> >
> > So it should be adding -100 to a 7 by 7 matrix of extended integers.
> >
> > And, for what it's worth, here's av, wv and zv in jtva2 (for comparison):
> > (gdb) p av
> > $15 = (C *) 0x555555768938 "p\022tUUU"
> > (gdb) p wv
> > $16 = (C *) 0x5555556d1648 "Ц}UUU"
> > (gdb) p zv
> > $17 = (C *) 0x5555556cfc48 "\300\017|UUU"
> >
> > and the point of failure in plusXX (where I've added audittstack calls
> > between every line) looks like this at the point of failure:
> > #2 0x00007ffff2e70879 in plusXX (n=-50, m=1, x=0x555555768940,
> > y=0x5555556d17a0, z=0x5555556cfda0, jt=0x7ffff13e8200)
> > at ../../../../jsrc/vx.c:368
> > 368 {if(MEMAUDIT&2)audittstack(jt);}
> >
> > ...
> >
> > There's a lot going on in jtva2, and there's a lot going on in the
> > memory management, but I'm wondering if maybe this is storing its
> > results to a bogus location - if that's the case I am not at all sure
> > that the details I am providing here are going to be all that useful
> > for isolating the problem.
> >
> > But I guess I could use a few more hints about where I should be looking...
> >
> > 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
