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