All,
I note that all of you who tested my code did not experience continuous memory leaks. I too experience a brief increase then decrease of the memory at the start of my tests but then it quickly settles in and continuously increases. Here are my results:
Test 1 - 1,000,000 Loops:Test 2 - Looping until Pi failure (hangs):
Photos of Pi 3B+ Screen at time of failure (see attachments):
Test Conclusion:
So both tests suggest that none you are getting the same memory leak as I am experiencing running the same simple code. So I think I can conclude that the python code is ok, Python version is ok, I think the Thonny version is irrelevant as the tests were run under lxTerminal. So I think we should now look at the operating system and the kernel. Let me know if you think there are more tests or checks I can perform before diving into OS/Kernels. I need to be guided by the guru's
NOTE: During Test 2 just before failure the memory did appear to pull back several times around the 97 to 98% mark. Jumping back 1%. It's almost like the memory is trying to free up at the start and end of Test 2 albeit very briefly. Thought I should mention this.
@Scruss: I agree with serial stuff but will park that for now and readdress after finding a fix for the fundamental memory leak. Good tips which I will employ. Thanks heaps.
Operating System used on my Pi 3B+:
The following was acquired via lxTerminal. I got the commands from RaspberryTips:
https://raspberrytips.com/which-raspber ... s-running/
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@raspberrypi:~ $ cat /etc/apt/sources.list.d/raspi.list
deb http://archive.raspberrypi.org/debian/ buster main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ buster main
pi@raspberrypi:~ $ uname -m
armv7l
pi@raspberrypi:~ $ getconf LONG_BIT
32
(Therefore 32 bit operating system)
pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:buster
Kernel Version:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
Is there anything that stands out in the OS and Kernel versions?
Note: If you think if worth its while I can get the same info from my Pi 4B+ which is also experiencing the memory leak. The second Pi 3B+ was simply a clone of the first and leaks. So for now, unless advised otherwise we'll just focus on the one Pi 3B+.
Regards,
Brian
I note that all of you who tested my code did not experience continuous memory leaks. I too experience a brief increase then decrease of the memory at the start of my tests but then it quickly settles in and continuously increases. Here are my results:
Test 1 - 1,000,000 Loops:
Code:
lxterminal TestStart of Test_1 - 1000000 loops:Test: 1004708 memory_percent: 20.3......(sometime later)Test: 1004708 memory_percent: 43.4Test: 1004709 memory_percent: 43.4Test: 1004710 memory_percent: 43.4Test: 1004711 memory_percent: 43.4Test: 1004712 memory_percent: 43.4Test: 1004713 memory_percent: 43.4Test: 1004714 memory_percent: 43.4Test: 1004715 memory_percent: 43.4Test: 1004716 memory_percent: 43.4
Code:
Start of Test_2 - loops until Pi failure:Test: 1004716 memory_percent: 20.1......(sometime later after Pi lockup)Test: 3813782 memory_percent: 98.2
Test Conclusion:
So both tests suggest that none you are getting the same memory leak as I am experiencing running the same simple code. So I think I can conclude that the python code is ok, Python version is ok, I think the Thonny version is irrelevant as the tests were run under lxTerminal. So I think we should now look at the operating system and the kernel. Let me know if you think there are more tests or checks I can perform before diving into OS/Kernels. I need to be guided by the guru's

NOTE: During Test 2 just before failure the memory did appear to pull back several times around the 97 to 98% mark. Jumping back 1%. It's almost like the memory is trying to free up at the start and end of Test 2 albeit very briefly. Thought I should mention this.
@Scruss: I agree with serial stuff but will park that for now and readdress after finding a fix for the fundamental memory leak. Good tips which I will employ. Thanks heaps.
Operating System used on my Pi 3B+:
The following was acquired via lxTerminal. I got the commands from RaspberryTips:
https://raspberrytips.com/which-raspber ... s-running/
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@raspberrypi:~ $ cat /etc/apt/sources.list.d/raspi.list
deb http://archive.raspberrypi.org/debian/ buster main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ buster main
pi@raspberrypi:~ $ uname -m
armv7l
pi@raspberrypi:~ $ getconf LONG_BIT
32
(Therefore 32 bit operating system)
pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:buster
Kernel Version:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
Is there anything that stands out in the OS and Kernel versions?
Note: If you think if worth its while I can get the same info from my Pi 4B+ which is also experiencing the memory leak. The second Pi 3B+ was simply a clone of the first and leaks. So for now, unless advised otherwise we'll just focus on the one Pi 3B+.
Regards,
Brian
Statistics: Posted by Brian Usher — Mon Jan 01, 2024 12:21 am