Hi Hans-Peter,
thank you dor reporting this. See my questions/comments below.
On 11/01/2018 01:53 PM, Hans-Peter
Sorge wrote:
Hello Jürgen,
here comes an other corner case.
The following two cases work as expected.
(⍳16)⍴'a'
SYSTEM LIMIT (rank)
(⍳16)⍴'a'
^ ^
(⍳16)⍴⊂'a'
SYSTEM LIMIT (rank)
(⍳16)⍴⊂'a'
^ ^
Good.
This case fails to detect the SYSTEM LIMIT and Kills the session:
12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
Killed
This is actually not hitting a system limit (unless you changed the
default values via ./configure:
⎕SYL[7;]
max. rank for APL values 8
But being killed is, of course not so good. But to troubleshoot this
I would need some more info
(and for this type of problem I cannot promise anything because
there are many root causes for them,
mostly ouside GNU APL itself.
Q1; what is your platform (operating system, CPU, wordsize?
I have a i686 32-bit CPI running Linux Mint and things work for me:
)CLEAR
CLEAR WS
⎕WA
3524751360
12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
WS FULL
12 10 13 14 12 14 13 14⍴⊂'0123456789abcdef'
^ ^
One difference here is the available menory: below 4Gig on my box
and 15Gig on yours.
Which raises the next question: pointer size.
Q3: what is the pointer size when you start GNU APL with -l 37 ?
Mine says:
eedjsa@server66:~/projects/juergen/apl-1.7/src$
./apl -l 37
sizeof(int) is 4
sizeof(void *) is 4
sizeof(Cell) is 20
sizeof(Svar_record) is 328
sizeof(Svar_partner) is 28
increasing rlimit RLIMIT_NPROC from 63490 to infinity
...
That means a void pointer (or any pointer for that matter) is 4 byte
= 32 bit which can
address up to 4 Gig which is fine. Your pointer size should be
larger, though, to address
16 Gig.
Q4 What does ]LOG 2 say? Unfortunately you example not only
stresses GNU APL but also
libc/malloc due to many nested values (each allocated separately).
Please compare the
behaviour of, say,:
⍴12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
with:
⍴12 10 13 14 12 14 13 (14×16) ⍴ 'A'
Both use a lot of memory but the first creates very many (nested) small APL values while
the second creates a single large APL value.
Q5: what does gdb say? Try
gdb ./apl
in the GNU APL src directory, then (in gdb):
run
then reproduce the fault and (back in gdb due to the crash:)
bt
which tells exactly where the crash happened. The information
displayed by bt (backtrace) would be important to me.
Q6: what is the output of cat /proc/meminfo on your box? E.g.
eedjsa@server66:~/projects/juergen/apl-1.7/src$ cat /proc/meminfo
MemTotal:8158432 kB
MemFree: 2061392 kB
Buffers: 388196 kB
Cached: 3553320 kB
...
Q7: what is the output of cat /proc/cpuinfo on your box? E.g.
eedjsa@server66:~/projects/juergen/apl-1.7/src$ cat /proc/meminfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
...
And some more oddities...
⎕WA
14988140544
⍴12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
WS FULL
⍴12 10 13 14 12 14 13 14⍴⊂'0123456789abcdef'
^ ^
⍴10 10 10 10 10 10 10 10 ⍴ ⊂'0123456789abcdef'
Killed (Getötet)
These are most likely incarnations of the same problem.
Best Regards,
/// Jürgen
Best Regards,
Hans-Peter
signature.asc
Description: OpenPGP digital signature
