Re: [Bug-apl] SYSTEM LIMIT not detected

[Juergen Sauermann]

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:

address@hidden:~/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.

address@hidden:~/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.

address@hidden:~/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