Re: [Jsource] thoughts about rewriting extended integer support

Mon, 27 Nov 2023 07:22:56 -0800

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





























					Reply via email to