On Thu, Dec 2, 2021 at 4:43 PM Marco van de Voort <f...@pascalprogramming.org> wrote:
> > Op 2-12-2021 om 14:37 schreef Mehmet Erol Sanliturk: > > The fault is not in the program . If it were in the program I am sure > > that it would produce a proper run time error . There is no such an > > error . The run is terminated from different parts of the program by > > the OSes after a ( large number of thousand ) recursive entries into > > almost > > all of the involved procedures covering a very large portion of ( > > around ) 12000 procedures during transaction processing which involves > > more recursions with respect to query . > > When only the query part is used there is no problem . During small > > transaction usage , again > > there is no problem . Increasing system defined run time stack size is > > not changing anything . > > > > ulimit limits? Does it also happen running as root? > > Debian seems to have a 8k ulimit by default. (type "ulimit -h") > <-------- This limit is defined for shell . > > At present my NFS server has not been running for more than a few years . If I start it I need to determine how to restart my work . This will take some time . I did not try Debian . Many years ago I attempted to use Debian , but I found that Mandriva was more suitable for me . When Mandriva closed down , I switched to Fedora . At present I am using Fedora 25 : [s@localhost ~]$ uname -a Linux localhost.localdomain 4.13.16-100.fc25.x86_64 #1 SMP Mon Nov 27 19:52:46 UTC 20 17 x86_64 x86_64 x86_64 GNU/Linux [s@localhost ~]$ [s@localhost ~]$ ulimit -h bash: ulimit: -h: invalid option ulimit: usage: ulimit [-SHabcdefilmnpqrstuvxT] [limit] [s@localhost ~]$ ulimit -H unlimited [s@localhost ~]$ [s@localhost ~]$ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30781 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30781 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [s@localhost ~]$ uname -a Linux localhost.localdomain 4.13.16-100.fc25.x86_64 #1 SMP Mon Nov 27 19:52:46 UTC 20 17 x86_64 x86_64 x86_64 GNU/Linux [s@localhost ~]$ Now I do not want to attempt to "improve" the existing operating systems because such improvements will not solve the inherent problems in developing and using large scale software stacks . Reasons are shortly defined below . My opinion about developing a new ( distributed and able to manage large software stacks ) operating system is really a very important goal , because the existent methods about software development and maintenance is causing large amount of losses ( time , effort , money , ... ) . This structure based on ( let's say around ) 1970 technology levels are not suitable for today's requirements . Many years ago when there was a need to a "secure programming language" for large military system supporting software , the Ada is selected , but failed , ( with respect to my memory ( which I may be wrong )) because (1) Ada was not able to compile itself due to its design , (2) The Ada compiler written in a "not-secure language" such as C could not produce a "secure compiler" for Ada . In those days , ( I do not remember name of the computing scientist who expressed the idea ) the expressed idea was " ... the present day software systems can not support development of required secure software for such a large military system ... " . Software development ( with all its components ) is not different from construction of buildings conceptually : It is possible to construct a 1-storey building by using earth-bags , but you can not stack three of them to construct a 3-storey building . You need to use brick at least . You can not construct a 9-storey building buy stacking three 3-storey buildings constructed from brick : You need to use concrete . . . . Such technology and material changes are required during construction of taller and taller buildings . During development of my program I have encountered a similar problem . When the size of the program increased , it became necessary to change the program development system . When the size of the program increased to a larger level , the used method again collapsed , it became necessary to change the program development method once more . These changes became necessary during increasing size of the program . All of the ideas presented in "Software Engineering" literature usable in small programs ( because they derived from small program projects ) are becoming useless during increasing size of the program . Instead of attempting "patching" of existing systems ( OS , compilers , etc. ) which they are developed for small systems and have significant problems for management of them , it is necessary to start a new set of software systems with a suitable design and implementation . Mehmet Erol Sanliturk
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus