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