As I promised, I conducted testing of both the development release (Build ef4dffb) and the stable release (Build 3043116) to see if I could replicate both the zombie and orphan issues I have been having while testing the DEBUG feature.
My conclusion is that zombie (and sometimes orphan processes) occur in both releases, and have nothing to do with the DEBUG updates.
I ran separate tests, one set with the stable release, the same programs in the development release (both without DEBUG and the third with DEBUG) and I get the same results. Every time I compile and run programs from the IDE, it creates a zombie process.
My computer setup is as follows: Dell Optiplex 990, with Intel® Core™ i5-2400 CPU @ 3.10GHz × 4, 32GB of RAM (Crucial RAM 4x8GB DDR3 1600 MHz CL11 Desktop Memory), running the latest updates of Linux Ubuntu 20.04.2 LTS. My primary hard drive is 500GB with a USB ProBox 4-bay HD storage device with 4 more SATA hard drives totaling 16TB.
After my last report where orphan processes were running just over 50 hours, I have not repeated this test (I plan on it, but wanted to reproduce the zombie process first).
The code I used for my testing is in this post (It was modified from a program by bplus) and all it does is display the character, binary number, ASCII code and hexadecimal code for ASCII 32 to 126. All display was to QB64's console. No compiles were done outside the IDE. No execution was launched from outside the IDE. Everything during the 3 tests outlined above were all done with the IDE.
I have looked at a test runs that I conducted outside of the IDE, where I wrote the code in the Geany Editor and used both the compile function from Geany and compiled on the command line using both QB64 directly and my BASH script I wrote, and doing more than 30 compiles and test runs of a program that integrates mySQL and BASH scripts providing args to them, I have not been able to reproduce the issues outlined here.
Common to all three types of testing and watching the progress, only after the third run (compile and execute from the IDE), 2 Zombie processes showed up! And from that point on, each successive run created a new zombie process.
I have provided in this post both screen prints of HTOP showing the zombie processes, and a log from my terminal showing the commands and results, such as MEMSTAT, PTREE and PS. I only provided one set of results, as they were the same across the three sets of testing I conducted.
In the three test sessions I performed, closing out QB64 did close out all the zombie processes. However, in the past as I have reported, this is not always the case. QB64 left orphans of itself and my system thought they were still running. With no active QB64 IDE or compiled code running, my screen prints from last week on Discord showed orphan processes that were still running (they were orphans because QB64 was closed down more than 24 hours before those screen prints were taken), even though QB64 was terminated normally. I even had PIDs of the program I was testing still running, even though everything was closed out properly more than 24 hours prior.
My system is running as a server that manages my devices in my house, so my system runs for weeks on end with no performance degradation, or any other issues. Only when QB64 is running, and I am doing many test runs and code changes using the IDE do I get severe system issues after many days.
I think it is time that someone looks into why this is happening. Before I did this test, I had both zombie and orphan processes, which crashed my machine before I could screen print and run my terminal commands to document them. As I discussed on Discord, I had closed out normally QB64, and all the programs I was running and testing over those three days ended normally.
And I do not accept as a solution to not run my system or development the way I do. It is not my behavior when coding or running my system as a server that is causing the issue, otherwise I would have similar issues with mySQL or Apache 2 Server.
Below are the screen prints from HTOP, and a log of commands I ran in terminal to show how these processes are tied in with each other. I also ran a MEMSTAT just to show what other programs are being used by QB64.
Here are the results from my Terminal commands:
(base) gjmcginn@optiplex990:~$ pidof qb64
18952
(base) gjmcginn@optiplex990:~$ memstat -p 18952
586892k: PID 18952 (/home/gjmcginn/qb64-development/qb64)
4k( 4k): /memfd:xshmfence 18952
4k( 4k): /memfd:xshmfence 18952
15004k( 15004k): anon_inode:i915.gem 18952
1284k( 1284k): /home/gjmcginn/.cache/mesa_shader_cache/index 18952
7024k( 6352k): /home/gjmcginn/qb64-development/qb64 18952
148k( 88k): /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0 18952
480k( 272k): /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 18952
676k( 584k): /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 18952
1916k( 964k): /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 18952
108k( 72k): /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 18952
184k( 140k): /usr/lib/x86_64-linux-gnu/ld-2.31.so 18952
540k( 128k): /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0 18952
456k( 332k): /usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 18952
144k( 108k): /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0 18952
228k( 56k): /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 18952
704k( 252k): /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0 18952
20k( 4k): /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 18952
24k( 8k): /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 18952
32k( 8k): /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 18952
84k( 44k): /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 18952
32k( 12k): /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 18952
28k( 12k): /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 18952
100k( 60k): /usr/lib/x86_64-linux-gnu/libbsd.so.0.10.0 18952
1976k( 1504k): /usr/lib/x86_64-linux-gnu/libc-2.31.so 18952
24k( 8k): /usr/lib/x86_64-linux-gnu/libdl-2.31.so 18952
80k( 40k): /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 18952
60k( 28k): /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1.0.1 18952
44k( 20k): /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 18952
184k( 112k): /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11 18952
1340k( 668k): /usr/lib/x86_64-linux-gnu/libm-2.31.so 18952
56k( 28k): /usr/lib/x86_64-linux-gnu/libnss_files-2.31.so 18952
44k( 20k): /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1 18952
124k( 68k): /usr/lib/x86_64-linux-gnu/libpthread-2.31.so 18952
28k( 8k): /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 18952
24k( 4k): /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 18952
116k( 36k): /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 18952
20k( 4k): /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 18952
20k( 4k): /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 18952
40k( 12k): /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 18952
40k( 12k): /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0.0.0 18952
168k( 80k): /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 18952
2056k( 4k): /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 18952
112k( 68k): /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 18952
1268k( 556k): /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 18952
14588k( 9596k): /usr/lib/x86_64-linux-gnu/dri/i965_dri.so 18952
--------
638528k ( 38672k)
(base) gjmcginn@optiplex990:~$ pstree -A -p -s 18952
systemd(1)---systemd(1519)---qb64(18952)-+-qb64(18983)
|-qb64(19010)
|-qb64(19035)
|-qb64(19061)
|-qb64(19322)
|-qb64(19345)
|-qb64(19374)
|-qb64(19399)
|-qb64(19427)
|-{qb64}(18953)
|-{qb64}(18954)
|-{qb64}(18955)
|-{qb64}(18958)
|-{qb64}(18959)
|-{qb64}(18960)
`-{qb64}(18961)
(base) gjmcginn@optiplex990:~$ ps ax | grep qb64
18952 ? Sl 2:05 ./qb64
18983 ? Z 0:00 [qb64] <defunct>
19010 ? Z 0:00 [qb64] <defunct>
19035 ? Z 0:00 [qb64] <defunct>
19061 ? Z 0:00 [qb64] <defunct>
19322 ? Z 0:00 [qb64] <defunct>
19345 ? Z 0:00 [qb64] <defunct>
19374 ? Z 0:00 [qb64] <defunct>
19399 ? Z 0:00 [qb64] <defunct>
19427 ? Z 0:00 [qb64] <defunct>
20077 pts/3 S+ 0:00 grep --color=auto qb64
(base) gjmcginn@optiplex990:~$ pstree -A -p -g -s -t 18952
systemd(1,1)---systemd(1519,1519)---qb64(18952,1924)-+-qb64(18983,1924)
|-qb64(19010,1924)
|-qb64(19035,1924)
|-qb64(19061,1924)
|-qb64(19322,1924)
|-qb64(19345,1924)
|-qb64(19374,1924)
|-qb64(19399,1924)
|-qb64(19427,1924)
|-{qb64:disk$0}(18958,1924)
|-{qb64:disk$1}(18959,1924)
|-{qb64:disk$2}(18960,1924)
|-{qb64:disk$3}(18961,1924)
|-{qb64}(18953,1924)
|-{qb64}(18954,1924)
`-{qb64}(18955,1924)
(base) gjmcginn@optiplex990:~$
Below are the two HTOP screen prints showing basically the same info above:
[ You are not allowed to view this attachment ]
[ You are not allowed to view this attachment ]
Here is a screen shot of my system details:
[ You are not allowed to view this attachment ]
Listing of System Details from my Terminal:
(base) gjmcginn@optiplex990:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
(base) gjmcginn@optiplex990:~$ hostnamectl
Static hostname: optiplex990
Pretty hostname: optiPlex990
Icon name: computer-desktop
Chassis: desktop
Machine ID: 88fa40fc6c1047309a1ad45fbe33b289
Boot ID: 5d3ddf0e33af417281ac967e0fb6154a
Operating System: Ubuntu 20.04.2 LTS
Kernel: Linux 5.11.0-25-lowlatency
Architecture: x86-64
(base) gjmcginn@optiplex990:~$
Here is the code I was running and compiling in the IDE:
_TITLE "ASCII-BIN-HEX Table" ' b+ 2021-08-04 count = 0
PRINT "CHARACTER, BINARY, ASCII, and HEX TABLE":
PRINT FOR i
= 32 TO 126 ' looks OK count = count + 1
PRINT " " + CHR$(i
);
" "; AscBin$
(i
);
VAL("&b" + AscBin$
(i
));
" ";
"0x" + HEX$(i
) count = 0
PRINT " " + CHR$(i
);
" "; AscBin$
(i
);
VAL("&b" + AscBin$
(i
));
" ";
"0x" + HEX$(i
),
IF (integerBase10
AND 2 ^ j
) > 0 THEN MID$(AscBin$
, 8 - j
, 1) = "1" + AscBin$
j = j + 1
