Please see if the folloing patch can fix part of the issues.
diff --git a/jsrc/vu.c b/jsrc/vu.c
index d969efd..a3e8767 100644
--- a/jsrc/vu.c
+++ b/jsrc/vu.c
@@ -25,7 +25,7 @@ A jttoc1(J jt,B h,A w){A z;C*wv,*zv;I n;C4*w4;
}
else
{
- if(h)DO(n, *zv++=(C)(0xff&*w4++);) else DO(n,
ASSERT(!(0xffffff00&*w4),EVDOMAIN); *zv++=(C)(0xff&*w4++); )
+ if(h)DO(n, *zv++=(UC)*w4++; ) else DO(n, *zv++=(UC)*w4++;
ASSERT(*(w4-1)<256UL,EVDOMAIN);)
}
// copy the low byte of the data (if there is any). if b==0, verify high
byte is 0
// where low and high are depends on endianness
@@ -36,7 +36,7 @@ A jttoc1(J jt,B h,A w){A z;C*wv,*zv;I n;C4*w4;
}
else
{
- if(h)DO(n, *zv++=(C)(0xff000000&*w4++);) else DO(n,
ASSERT(!(0xffffff&*w4),EVDOMAIN); *zv++=(C)(0xff000000&*w4++); )
+ if(h)DO(n, *zv++=(UC)*w4++; ) else DO(n, *zv++=(UC)*w4++;
ASSERT(*(w4-1)<256UL,EVDOMAIN);)
}
#endif
R z;
> (10&u:'5')</.i.1
> (10&u:'5') ({.,#)/. 0
> (#/.~)10&u:'5'
These seems special codes, try if covered verbs can produce
meaningful results. eg
box=: <
tally=: #
(10&u:'5')box/.i.1
(10&u:'5') ({.,tally)/. 0
(tally/.~)10&u:'5'
and see if c4range in vg.c can return reasonable base and top.
Чт, 15 сен 2016, Xiao-Yong Jin написал(а):
> I was hoping you guys might immediately realize some bit manipulations in the
> new code may depend on machine bit order. I can try to dig deeper and we can
> probably solve it with your help, and I can learn more about your code.
>
> Let’s start from some simple cases, and perhaps that could shed some light on
> the cause of seg faults.
>
> >>
> >> g128x3 failed at (f 6&u: x) = f , _2 Endian \ x
> >> I have (f 6&u: x) , f , _2 Endian \ x
> >> gives 784552940 1897224108
> >
> > perhaps the test is wrong, try
> > (f 6&u: x) = f x
> This returns 1, and f x matches the results with the one on a little endian
> machine. So the test may be wrong.
>
> >> g8x failed at (( 10&u:'5') fmt y) -: '5' fmt y=: 3 4
> >> ?@$ 0
> >> |domain error: fmt
> >> | ((10&u:'5') fmt y)-:'5'fmt y=:3 4?@$0
> >
> > please confirm whether 5&u:(10&u:'5') and 1&u:(10&u:'5')
> > can give '5' without domain error.
> I got
>
> 5&u:(10&u:'5')
> |domain error
> | 5&u:(10&u:'5')
> 1&u:(10&u:'5')
>
> 3!:3[1&u:(10&u:'5')
> e200000000000000
> 0000000000000002
> 0000000000000001
> 0000000000000000
> 0000000000000000
> 3!:3(10&u:'5')
> e200000000000000
> 0000000000040000
> 0000000000000001
> 0000000000000000
> 0000003500000000
> 10&u:'5'
> 5
>
> The first one got domain error and the second one returns empty. 10&u:'5'
> gives the correct result. What could be the culprit? Let me know which part
> of the code I should poke into.
>
> About the g421*, I got consistent segmentation faults with the following
> sentences.
> (10&u:'5')</.i.1
> (10&u:'5') ({.,#)/. 0
> (#/.~)10&u:'5'
>
>
> The rest of failures associated with u: are probably related.
> The issues with gdll_df and gstack are certainly unrelated with unicode, but
> if you have any ideas let me know.
>
>
> > On Sep 14, 2016, at 6:48 AM, bill lam <bbill....@gmail.com> wrote:
> >
> > The crash in g4xx are sorting/grading on literal4. I will not be
> > surprised if it contains bugs but since I cannot test myself
> > therefore I can't help much too.
> >
> > Ср, 14 сен 2016, Henry Rich написал(а):
> >> I can't help much. If you can figure out which sentence is failing, that
> >> would be a clue.
> >>
> >> Henry Rich
> >>
> >> On 9/14/2016 12:07 AM, Xiao-Yong Jin wrote:
> >>> Dear List,
> >>>
> >>> I’m compiling the jsource from github on a linux ppc64 box, which is big
> >>> endian.
> >>> Using commit
> >>> 4ebc317 - Use flags in derived verbs; and a bug fix (30 hours ago)
> >>> <HenryHRich>
> >>> with gcc 4.4.7 and additional options of -DC_NA=1 -DC_LE=0
> >>>
> >>> I met segmentation faults in the following test scripts:
> >>> g421c seg faults at test adot2
> >>> in jtgroup (jt=0x10029119930, w=0x10029239760)
> >>> at jsrc/ao.c:378
> >>> g421d seg faults at test adot2
> >>> jtkeytally (jt=0x10035279930, a=0x10035399760,
> >>> w=0xfff95653820, self=0x100352cb870)
> >>> at jsrc/ao.c:437
> >>> g421t seg faults at test adot2
> >>> in jtkeytally (jt=0x10010829930, a=0x10010948750,
> >>> w=0x10010948750, self=0xfff9f027720)
> >>> at jsrc/ao.c:437
> >>> gstack seg faults at 'stack error' -: ex '".t' [ t=: '".t'
> >>> in jtgaf (jt=0x0, blockx=0)
> >>> at jsrc/m.c:451
> >>>
> >>> I can provide detailed back trace if any of you are interested, but it
> >>> seems some of the address dereferencing point to unavailable regions.
> >>> For example, in jsrc/ao.c:378, dv did not point to a valid address when
> >>> GRPCD(C4) is called.
> >>>
> >>> After blacklisting those tests, I got following failing tests:
> >>> RBAD''[RUN ddall
> >>> g128x3 failed at (f 6&u: x) = f , _2 Endian \ x
> >>> I have (f 6&u: x) , f , _2 Endian \ x
> >>> gives 784552940 1897224108
> >>> g8x failed at (( 10&u:'5') fmt y) -: '5' fmt y=: 3 4
> >>> ?@$ 0
> >>> |domain error: fmt
> >>> | ((10&u:'5') fmt y)-:'5'fmt y=:3 4?@$0
> >>> gdll_df failed at (6.6;3;1.1 2.2 3.3;,6.6)= 'dipdpd d i *d
> >>> *d' dcd 3;1.1 2.2 3.3;,1.1
> >>> |domain error: cd
> >>> | (lib,x) cd y
> >>> gebar failed at 'a' (ebar -: E.) 10&u:'a’
> >>> I have 'a' (ebar , E.) 10&u:'a’
> >>> gives 1 1
> >>> no idea why it failed…
> >>> gicap2 failed at 2 test1 a.
> >>> |assertion failure: test1
> >>> | (yy le"_1 i{xx,{:xx) +.(i=#xx)*.yy
> >>> gt"_1 _{:xx
> >>> gmbxx1u failed at (mbxcheck_jmf_ q), (7!:6 (5&u:&.>) q) -:
> >>> 7!:6 (5&u:&.>) x
> >>> |domain error: RUND1
> >>> | (mbxcheck_jmf_ q),(7!:6(5&u:&.>)q)-:7!:6
> >>> (5&u:&.>)x
> >>> |[-103] gmbxx1u.ijs
> >>> gu0 failed at t -: 1 u: x
> >>> I don’t think 1 u: x is doing the correct thing.
> >>>
> >>> It seems that most of the breakage happens at handling of the unicode.
> >>> Perhaps the code had assumed little endian, since the same code works
> >>> fine on an intel linux box.
> >>>
> >>> For comparison, I reverted back to commit:
> >>> 9562630 - Commentary for u/. y; and fix error in #:y for negative float
> >>> y (4 months ago) <HenryHRich>
> >>> With this, I got one segfaults with gstack, and failing tests in
> >>> g3x
> >>> gchar
> >>> gdll_df
> >>>
> >>> Let me know how I can help chasing these bugs away.
> >>>
> >>> Best,
> >>> Xiao-Yong
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >
> > --
> > regards,
> > ====================================================
> > GPG key 1024D/4434BAB3 2008-08-24
> > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
