[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] SYSTEM LIMIT not detected

From: Juergen Sauermann
Subject: Re: [Bug-apl] SYSTEM LIMIT not detected
Date: Thu, 1 Nov 2018 18:37:25 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.

      ^    ^
      ^     ^
This case fails to detect the SYSTEM LIMIT and Kills the session:

      12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
This is actually not hitting a system limit (unless you changed the default values via ./configure:

 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:


      12 10 13 14 12 14 13 14 ⍴ ⊂'0123456789abcdef'
      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'

⍴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):


then reproduce the fault and (back in gdb due to the crash:)


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...

      ⍴12 10 13 14 12 14 13 14  ⍴ ⊂'0123456789abcdef'
      ⍴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,


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]