summaryrefslogtreecommitdiff
path: root/HISTORY.rst
Commit message (Collapse)AuthorAgeFilesLines
* fix typos and some other minor bugs (#2253)HEADmastercui fliter2023-05-091-1/+1
| | | Signed-off-by: cui fliter <imcusg@gmail.com>
* fix failing users() test; update HISTORY; give CREDITS to @0-wiz-0 for #2241Giampaolo Rodola2023-04-201-0/+8
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* pre releaserelease-5.9.5Giampaolo Rodola2023-04-171-2/+4
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* Add CI testing for OpenBSD and NetBSD (#2240)Giampaolo Rodola2023-04-171-0/+2
|
* Fix #2239 / proc name(): don't fail with ZombieProcess on cmdline()Giampaolo Rodola2023-04-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent failure observed on OpenBSD led me to an interesting consideration. ``` ====================================================================== ERROR: psutil.tests.test_process.TestProcess.test_long_name ---------------------------------------------------------------------- Traceback (most recent call last): File "/vagrant/psutil/psutil/_psbsd.py", line 566, in wrapper return fun(self, *args, **kwargs) File "/vagrant/psutil/psutil/_psbsd.py", line 684, in cmdline return cext.proc_cmdline(self.pid) ProcessLookupError: [Errno 3] No such process During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/vagrant/psutil/psutil/tests/test_process.py", line 751, in test_long_name self.assertEqual(p.name(), os.path.basename(testfn)) File "/vagrant/psutil/psutil/__init__.py", line 628, in name cmdline = self.cmdline() File "/vagrant/psutil/psutil/__init__.py", line 681, in cmdline return self._proc.cmdline() File "/vagrant/psutil/psutil/_psbsd.py", line 569, in wrapper raise ZombieProcess(self.pid, self._name, self._ppid) psutil.ZombieProcess: PID still exists but it's a zombie (pid=48379) ---------------------------------------------------------------------- ``` The exception above occurs sporadically. It originates from `sysctl (KERN_PROC_ARGV)`: https://github.com/giampaolo/psutil/blob/0a81fa089fd4b25b4b7ee71ed39213b83f73c052/psutil/arch/openbsd/proc.c#L149 The error per se does not represent a bug in the OpenBSD `cmdline ()` implemention because the process **really** is a zombie at that point (I'm not sure why it's a zombie - this seems only to occur only on OpenBSD for this specific test case - but that's not the point). The interesting thing is that the test calls process `name()` (which succeeds, despite it's a zombie process), but since the process name is too long it gets truncated to 15 chars (this is a UNIX thing) so psutil tries to guess the remaining characters from the process `cmdline()`, which fails: https://github.com/giampaolo/psutil/blob/0a81fa089fd4b25b4b7ee71ed39213b83f73c052/psutil/__init__.py#L623-L630 The problem to fix here is that, if `name()` succeeds but `cmdline()` fails, we should not raise `ZombieProcess`: we should simply return the (truncated) process `name()` instead, because that is better than nothing. Not on OpenBSD but on all platforms. Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* fix #2238 if cwd() cannot be determined always return "" instead of NoneGiampaolo Rodola2023-04-171-2/+6
|
* Fix #2237, OpenBSD, cwd(): return None instead of FileNotFoundErrorGiampaolo Rodola2023-04-161-0/+2
|
* Fix #2236 / NetNBSD: skip terminated process threadsGiampaolo Rodola2023-04-141-0/+2
| | | | | | | | | Process threads() and num_threads() methods now skip threads which are in ZOMBIE or IDLE state. It turns out that after a thread is terminated / join()ed, instead of disappearing it can stick around in a ZOMBIE or IDLE state, presumably for a while before being garbage collected. Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* [NetBSD] virtual_memory() metrics are completely wrong (#2235), fixes #2234Giampaolo Rodola2023-04-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Match values shown by **htop**. This is before. In here: * available mem is almost the same as total (unrealistic) * used is higher than total; there's also a failing test: ``` MEMORY ------ Total : 972.7M Available : 959.1M Percent : 1.4 Used : 1.1G Free : 173.6M Active : 434.3M Inactive : 258.4M Buffers : 509.4M Cached : 692.9M Shared : 0.0B Wired : 280.0K ``` Now: ``` MEMORY ------ Total : 972.7M Available : 538.1M Percent : 44.7 Used : 434.5M Free : 173.6M Active : 434.2M Inactive : 258.4M Buffers : 509.4M Cached : 692.9M Shared : 0.0B Wired : 280.0K ```
* [NetBSD] available mem can be higher than total (#2233)Giampaolo Rodola2023-04-141-0/+1
| | | | | | | | | | | | | | | | | On NetBSD "available" memory can be higher than "total". From now now calculate it exactly the same as Zabbix: https://github.com/zabbix/zabbix/blob/af5e0f80253e585ca7082ca6bc9cc07400afe2a7/src/libs/zbxsysinfo/netbsd/memory.c Fixes https://github.com/giampaolo/psutil/issues/2231 which produced this failure: ``` ====================================================================== FAIL: psutil.tests.test_system.TestMemoryAPIs.test_virtual_memory ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/vagrant/psutil/psutil/tests/test_system.py", line 275, in test_virtual_memory assert 0 <= mem.percent <= 100, mem ^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: svmem(total=1019899904, available=1046573056, percent=-2.6, used=603414528, free=545050624, active=234807296, inactive=133210112, buffers=260288512, cached=368312320, shared=0, wired=294912) ```
* OpenBSD: rewrite net_connections() from scratch (#2230)Giampaolo Rodola2023-04-131-0/+7
|
* Get Windows percent swap usage from performance counters (#2160)Daniel Widdis2023-04-131-0/+2
| | | Signed-off-by: Daniel Widdis <widdis@gmail.com>
* OpenBSD is unable to recognize zombie process. (#2229)Giampaolo Rodola2023-04-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenBSD is unable to recognize zombie process. It will raise NoSuchProcess instead of ZombieProcess. Test failure: ====================================================================== ERROR: psutil.tests.test_process.TestProcess.test_zombie_process ---------------------------------------------------------------------- Traceback (most recent call last): File "/vagrant/psutil/psutil/_psbsd.py", line 560, in wrapper return fun(self, *args, **kwargs) File "/vagrant/psutil/psutil/_psbsd.py", line 862, in open_files rawlist = cext.proc_open_files(self.pid) ProcessLookupError: [Errno 3] No such process During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/vagrant/psutil/psutil/tests/test_process.py", line 1312, in test_zombie_process zproc.as_dict() File "/vagrant/psutil/psutil/__init__.py", line 528, in as_dict ret = meth() File "/vagrant/psutil/psutil/__init__.py", line 1142, in open_files return self._proc.open_files() File "/vagrant/psutil/psutil/_psbsd.py", line 565, in wrapper raise NoSuchProcess(self.pid, self._name) psutil.NoSuchProcess: process no longer exists (pid=67013) This happens because OpenBSD is the only BSD defining 2 codes for zombie processes: # According to /usr/include/sys/proc.h SZOMB is unused. # test_zombie_process() shows that SDEAD is the right # equivalent. Also it appears there's no equivalent of # psutil.STATUS_DEAD. SDEAD really means STATUS_ZOMBIE. # cext.SZOMB: _common.STATUS_ZOMBIE, cext.SDEAD: _common.STATUS_ZOMBIE, cext.SZOMB: _common.STATUS_ZOMBIE,
* [POSIX] psutil.users() loses precision for "started" attribute #2225 (#2226)Giampaolo Rodola2023-04-111-0/+2
|
* [Linux] guess `available` virtual_memory() if kernel says it's 0 (#2052)Giampaolo Rodola2023-03-291-0/+4
| | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* update HISTORYGiampaolo Rodola2023-03-281-0/+2
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* update HISTORY/CREDITS for #2216 / @mayeutGiampaolo Rodola2023-03-271-0/+2
|
* Clearer tracebacks in case of chained exceptions (#2196)Giampaolo Rodola2023-01-241-0/+10
| | | | | | In case of exception, display a cleaner error traceback by hiding the `KeyError` bit deriving from a missed cache hit. Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* give CREDITS to @sunpoet for #2186Giampaolo Rodola2022-12-271-0/+1
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* #2164: fix compilation failures on linux < 2.6.27 / CentOS 5 (#2171)Giampaolo Rodola2022-11-101-0/+5
|
* pre releaseGiampaolo Rodola2022-11-071-3/+3
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* update HISTORY + give CREDITS for @arossert, @smoofra, @mayeut for #2102, ↵Giampaolo Rodola2022-10-211-1/+11
| | | | #2156, #2010
* Use system-level values for Windows virtual memory (#2077)Daniel Widdis2022-10-211-0/+10
| | | | | | | | | | | | | | | | | * Use system-level values for Windows virtual memory Submitting this as a draft PR as I believe it will address #2074. I do not have either a C or Python development environment to test these changes, so they are provided in the hopes someone else can test and confirm they fix the issue. There's probably some room to simplify the code with temporary variables to reduce redundancy. For background, I have implemented precisely this logic in my own (Java-based) project [here](https://github.com/oshi/oshi/blob/3bb9eafbe2062edad4108b7b12501b1f9be27361/oshi-core/src/main/java/oshi/hardware/platform/windows/WindowsVirtualMemory.java#L110-L118) and [here](https://github.com/oshi/oshi/blob/3bb9eafbe2062edad4108b7b12501b1f9be27361/oshi-core/src/main/java/oshi/hardware/platform/windows/WindowsGlobalMemory.java#L253-L263) following a detailed investigation in https://github.com/oshi/oshi/issues/1182 Signed-off-by: Daniel Widdis <widdis@gmail.com> * Formatting, credits, change log Signed-off-by: Daniel Widdis <widdis@gmail.com> Signed-off-by: Daniel Widdis <widdis@gmail.com>
* pre-release + give CREDITS to @mayeut (PR #2040) and @eallrich (new supporter)release-5.9.3Giampaolo Rodola2022-10-181-3/+8
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* fix: race condition in test_posix.TestProcess.test_cmdline (#2153)Matthieu Darbois2022-10-081-0/+2
|
* fix: disk usage report on macOS 12+ (#2152)Matthieu Darbois2022-10-051-0/+1
|
* Resolve race condition in Process.threads() (#2151)Daniel Li2022-09-291-0/+2
| | | | | | | | | | | | | | | | | * Resolve race condition in Process.threads() Process.threads() has a race condition triggered when a thread exits after the open_binary() call and before the read() call. When this happens, the read() call raises ProcessLookupError. Handle the race condition by catching ProcessLookupError from read() and treating the same as a FileNotFoundError from open_binary(). This is the same approach used in ppid_map(). Signed-off-by: Daniel Li <daniel.li@deshaw.com> * Also catch ProcessLookupError in open_files() Signed-off-by: Daniel Li <daniel.li@deshaw.com>
* #2104 / TestFetchAllProcesses: don't use process pool on CI (fix deadlock)Giampaolo Rodola2022-09-201-1/+1
|
* fix #2116, macOS, net_connections() crashingGiampaolo Rodola2022-09-191-0/+1
| | | | | | It turns out that proc_pidinfo() crashes for PID 0 Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* fix #2138 (critical): re-define ethtool_cmd_speedGiampaolo Rodola2022-09-191-0/+2
|
* resolve conflictsGiampaolo Rodola2022-09-191-8/+8
|\ | | | | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
| * Fix typosKian-Meng Ang2022-01-271-8/+8
| |
* | [macOS] Fix out-of-bounds read around sysctl_procargs (#2135)Bernhard Urban-Forster2022-09-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The buffer size is initially determined by querying `argmax`: https://github.com/giampaolo/psutil/blob/9f9a82d02c901f62512236b44edb050f84cbe5b6/psutil/arch/osx/process_info.c#L260-L265 This length is passed to the `sysctl()` call for querying the procargs. `sysctl()` is allowed to set it to a smaller value, to indicate the buffer wasn't fully used. However this is not passed back to the caller "owning" that memory, and also parsing the result. Depending on the allocator, it's possible that we can observe "garbage" values, consider this example: ```python import psutil import subprocess import os import sys environment_cookie = "__MAGIC_ENV_COOKIE__" for i in range(0,200): os.environ["PATH"] = os.environ.get("PATH", "") + os.pathsep + environment_cookie + str(i) print("sys.executable: " + str(sys.executable)) exe = os.path.split(sys.executable)[1] exe = exe.split(".")[0] print("exe: " + str(exe)) polluted_process = subprocess.Popen([exe, "-c", "import time; time.sleep(3)"], env=os.environ.copy()) clean_process = subprocess.Popen([exe, "-c", "import time; time.sleep(3)"], env={}) print("polluted pid=" + str(polluted_process.pid)) print("clean pid=" + str(clean_process.pid)) pp = psutil.Process(polluted_process.pid) pc = psutil.Process(clean_process.pid) for i in range(0,8): pp.environ() for i in range(0,8): e = pc.environ() if len(e) > 0: print("clean subprocess (should be empty) env=" + str(e)) exit(2) print("no repro, try again :-/") ``` In order to better illustrate the problem, I added this debug output to `psutils`: ```diff +++ psutil/arch/osx/process_info.c @@ -263,6 +263,7 @@ psutil_get_environ(pid_t pid) { goto error; procargs = (char *)malloc(argmax); + printf("[psutil_get_environ] pid=%d, procargs=%p\n", pid, procargs); if (NULL == procargs) { PyErr_NoMemory(); goto error; ``` Example output: ``` $ python3 .py sys.executable: /opt/homebrew/opt/python@3.10/bin/python3.10 exe: python3 polluted pid=63479 clean pid=63480 [psutil_get_environ] pid=63479, procargs=0x140088000 [psutil_get_environ] pid=63479, procargs=0x140188000 [psutil_get_environ] pid=63479, procargs=0x140088000 [psutil_get_environ] pid=63479, procargs=0x140188000 [psutil_get_environ] pid=63479, procargs=0x140088000 [psutil_get_environ] pid=63479, procargs=0x140188000 [psutil_get_environ] pid=63479, procargs=0x140088000 [psutil_get_environ] pid=63479, procargs=0x140188000 [psutil_get_environ] pid=63480, procargs=0x140088000 clean subprocess (should be empty) env={'EDITOR': 'vim', [[removed]], 'PATH': '/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:__MAGIC_ENV_COOKIE__0:__MAGIC_ENV_COOKIE__1:__MAGIC_ENV_COOKIE__2:__MAGIC_ENV_COOKIE__3:__MAGIC_ENV_COOKIE__4:__MAGIC_ENV_COOKIE__5:__MAGIC_ENV_COOKIE__6:__MAGIC_ENV_COOKIE__7:__MAGIC_ENV_COOKIE__8:__MAGIC_ENV_COOKIE__9:__MAGIC_ENV_COOKIE__10:__MAGIC_ENV_COOKIE__11:__MAGIC_ENV_COOKIE__12:__MAGIC_ENV_COOKIE__13:__MAGIC_ENV_COOKIE__14:__MAGIC_ENV_COOKIE__15:__MAGIC_ENV_COOKIE__16:__MAGIC_ENV_COOKIE__17:__MAGIC_ENV_COOKIE__18:__MAGIC_ENV_COOKIE__19:__MAGIC_ENV_COOKIE__20:__MAGIC_ENV_COOKIE__21:__MAGIC_ENV_COOKIE__22:__MAGIC_ENV_COOKIE__23:__MAGIC_ENV_COOKIE__24:__MAGIC_ENV_COOKIE__25:__MAGIC_ENV_COOKIE__26:__MAGIC_ENV_COOKIE__27:__MAGIC_ENV_COOKIE__28:__MAGIC_ENV_COOKIE__29:__MAGIC_ENV_COOKIE__30:__MAGIC_ENV_COOKIE__31:__MAGIC_ENV_COOKIE__32:__MAGIC_ENV_COOKIE__33:__MAGIC_ENV_COOKIE__34:__MAGIC_ENV_COOKIE__35:__MAGIC_ENV_COOKIE__36:__MAGIC_ENV_COOKIE__37:__MAGIC_ENV_COOKIE__38:__MAGIC_ENV_COOKIE__39:__MAGIC_ENV_COOKIE__40:__MAGIC_ENV_COOKIE__41:__MAGIC_ENV_COOKIE__42:__MAGIC_ENV_COOKIE__43:__MAGIC_ENV_COOKIE__44:__MAGIC_ENV_COOKIE__45:__MAGIC_ENV_COOKIE__46:__MAGIC_ENV_COOKIE__47:__MAGIC_ENV_COOKIE__48:__MAGIC_ENV_COOKIE__49:__MAGIC_ENV_COOKIE__50:__MAGIC_ENV_COOKIE__51:__MAGIC_ENV_COOKIE__52:__MAGIC_ENV_COOKIE__53:__MAGIC_ENV_COOKIE__54:__MAGIC_ENV_COOKIE__55:__MAGIC_ENV_COOKIE__56:__MAGIC_ENV_COOKIE__57:__MAGIC_ENV_COOKIE__58:__MAGIC_ENV_COOKIE__59:__MAGIC_ENV_COOKIE__60:__MAGIC_ENV_COOKIE__61:__MAGIC_ENV_COOKIE__62:__MAGIC_ENV_COOKIE__63:__MAGIC_ENV_COOKIE__64:__MAGIC_ENV_COOKIE__65:__MAGIC_ENV_COOKIE__66:__MAGIC_ENV_COOKIE__67:__MAGIC_ENV_COOKIE__68:__MAGIC_ENV_COOKIE__69:__MAGIC_ENV_COOKIE__70:__MAGIC_ENV_COOKIE__71:__MAGIC_ENV_COOKIE__72:__MAGIC_ENV_COOKIE__73:__MAGIC_ENV_COOKIE__74:__MAGIC_ENV_COOKIE__75:__MAGIC_ENV_COOKIE__76:__MAGIC_ENV_COOKIE__77:__MAGIC_ENV_COOKIE__78:__MAGIC_ENV_COOKIE__79:__MAGIC_ENV_COOKIE__80:__MAGIC_ENV_COOKIE__81:__MAGIC_ENV_COOKIE__82:__MAGIC_ENV_COOKIE__83:__MAGIC_ENV_COOKIE__84:__MAGIC_ENV_COOKIE__85:__MAGIC_ENV_COOKIE__86:__MAGIC_ENV_COOKIE__87:__MAGIC_ENV_COOKIE__88:__MAGIC_ENV_COOKIE__89:__MAGIC_ENV_COOKIE__90:__MAGIC_ENV_COOKIE__91:__MAGIC_ENV_COOKIE__92:__MAGIC_ENV_COOKIE__93:__MAGIC_ENV_COOKIE__94:__MAGIC_ENV_COOKIE__95:__MAGIC_ENV_COOKIE__96:__MAGIC_ENV_COOKIE__97:__MAGIC_ENV_COOKIE__98:__MAGIC_ENV_COOKIE__99:__MAGIC_ENV_COOKIE__100:__MAGIC_ENV_COOKIE__101:__MAGIC_ENV_COOKIE__102:__MAGIC_ENV_COOKIE__103:__MAGIC_ENV_COOKIE__104:__MAGIC_ENV_COOKIE__105:__MAGIC_ENV_COOKIE__106:__MAGIC_ENV_COOKIE__107:__MAGIC_ENV_COOKIE__108:__MAGIC_ENV_COOKIE__109:__MAGIC_ENV_COOKIE__110:__MAGIC_ENV_COOKIE__111:__MAGIC_ENV_COOKIE__112:__MAGIC_ENV_COOKIE__113:__MAGIC_ENV_COOKIE__114:__MAGIC_ENV_COOKIE__115:__MAGIC_ENV_COOKIE__116:__MAGIC_ENV_COOKIE__117:__MAGIC_ENV_COOKIE__118:__MAGIC_ENV_COOKIE__119:__MAGIC_ENV_COOKIE__120:__MAGIC_ENV_COOKIE__121:__MAGIC_ENV_COOKIE__122:__MAGIC_ENV_COOKIE__123:__MAGIC_ENV_COOKIE__124:__MAGIC_ENV_COOKIE__125:__MAGIC_ENV_COOKIE__126:__MAGIC_ENV_COOKIE__127:__MAGIC_ENV_COOKIE__128:__MAGIC_ENV_COOKIE__129:__MAGIC_ENV_COOKIE__130:__MAGIC_ENV_COOKIE__131:__MAGIC_ENV_COOKIE__132:__MAGIC_ENV_COOKIE__133:__MAGIC_ENV_COOKIE__134:__MAGIC_ENV_COOKIE__135:__MAGIC_ENV_COOKIE__136:__MAGIC_ENV_COOKIE__137:__MAGIC_ENV_COOKIE__138:__MAGIC_ENV_COOKIE__139:__MAGIC_ENV_COOKIE__140:__MAGIC_ENV_COOKIE__141:__MAGIC_ENV_COOKIE__142:__MAGIC_ENV_COOKIE__143:__MAGIC_ENV_COOKIE__144:__MAGIC_ENV_COOKIE__145:__MAGIC_ENV_COOKIE__146:__MAGIC_ENV_COOKIE__147:__MAGIC_ENV_COOKIE__148:__MAGIC_ENV_COOKIE__149:__MAGIC_ENV_COOKIE__150:__MAGIC_ENV_COOKIE__151:__MAGIC_ENV_COOKIE__152:__MAGIC_ENV_COOKIE__153:__MAGIC_ENV_COOKIE__154:__MAGIC_ENV_COOKIE__155:__MAGIC_ENV_COOKIE__156:__MAGIC_ENV_COOKIE__157:__MAGIC_ENV_COOKIE__158:__MAGIC_ENV_COOKIE__159:__MAGIC_ENV_COOKIE__160:__MAGIC_ENV_COOKIE__161:__MAGIC_ENV_COOKIE__162:__MAGIC_ENV_COOKIE__163:__MAGIC_ENV_COOKIE__164:__MAGIC_ENV_COOKIE__165:__MAGIC_ENV_COOKIE__166:__MAGIC_ENV_COOKIE__167:__MAGIC_ENV_COOKIE__168:__MAGIC_ENV_COOKIE__169:__MAGIC_ENV_COOKIE__170:__MAGIC_ENV_COOKIE__171:__MAGIC_ENV_COOKIE__172:__MAGIC_ENV_COOKIE__173:__MAGIC_ENV_COOKIE__174:__MAGIC_ENV_COOKIE__175:__MAGIC_ENV_COOKIE__176:__MAGIC_ENV_COOKIE__177:__MAGIC_ENV_COOKIE__178:__MAGIC_ENV_COOKIE__179:__MAGIC_ENV_COOKIE__180:__MAGIC_ENV_COOKIE__181:__MAGIC_ENV_COOKIE__182:__MAGIC_ENV_COOKIE__183:__MAGIC_ENV_COOKIE__184:__MAGIC_ENV_COOKIE__185:__MAGIC_ENV_COOKIE__186:__MAGIC_ENV_COOKIE__187:__MAGIC_ENV_COOKIE__188:__MAGIC_ENV_COOKIE__189:__MAGIC_ENV_COOKIE__190:__MAGIC_ENV_COOKIE__191:__MAGIC_ENV_COOKIE__192:__MAGIC_ENV_COOKIE__193:__MAGIC_ENV_COOKIE__194:__MAGIC_ENV_COOKIE__195:__MAGIC_ENV_COOKIE__196:__MAGIC_ENV_COOKIE__197:__MAGIC_ENV_COOKIE__198:__MAGIC_ENV_COOKIE__199'} ``` As you can see the allocated buffer for `pid=63480` matches with some instances of `pid=63479`. Kudos to @naoufal450 and @gilles-duboscq for debugging this issue! Signed-off-by: Bernhard Urban-Forster <bernhard.urban-forster@oracle.com> Signed-off-by: Bernhard Urban-Forster <bernhard.urban-forster@oracle.com> Co-authored-by: Giampaolo Rodola <g.rodola@gmail.com>
* | update version + HISTORY + CREDITS for #2138Giampaolo Rodola2022-09-191-0/+10
| |
* | Add in support for network interface flags. (#2037)Chris Lalancette2022-09-061-0/+1
| | | | | | | | Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
* | fix venvrelease-5.9.2Giampaolo Rodola2022-09-041-9/+9
| |
* | update HISTORY + bump up versionGiampaolo Rodola2022-09-021-7/+12
| |
* | FreeBSD / pids(): increase buf size if not enoughGiampaolo Rodola2022-09-021-1/+3
| | | | | | | | | | ...dynamically, in case of ENOMEM, instead of crashing. Fixes #2093.
* | [NetBSD] two fixes for swap code (#2128)Thomas Klausner2022-08-181-0/+1
| |
* | [Linux] `net_if_stats()` returns an incorrect speed value for 100GbE network ↵garrisoncarter2022-07-111-0/+2
| | | | | | | | cards (#2096)
* | Implicitly include <sys/param.h> so that __FreeBSD_version checks wor… (#2114)Torsten-B2022-06-241-0/+5
| |
* | pre releaserelease-5.9.1Giampaolo Rodola2022-05-201-5/+6
| |
* | [Linux] Speedup `Process.full_memory_info()` (#2108)Giampaolo Rodola2022-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `Process.memory_full_info()` (reporting proecss USS/PSS/Swap memory) now reads ``/proc/pid/smaps_rollup`` instead of ``/proc/pids/smaps`` which makes it 5 times faster. Without patch: ``` ~/svn/psutil {linux-smaps-rollup}$ python3 -m timeit -s "import psutil; p = psutil.Process()" "p.memory_full_info()" 500 loops, best of 5: 518 usec per loop ``` With patch (5 times faster): ``` ~/svn/psutil {linux-smaps-rollup}$ python3 -m timeit -s "import psutil; p = psutil.Process()" "p.memory_full_info()" 2000 loops, best of 5: 111 usec per loop ``` ---- `make test-memleaks` suite, who heavily rely on `Process.memory_full_info()`, also received a nice speedup: Before patch: ``` $ make test-memleaks ---------------------------------------------------------------------- Ran 99 tests in 1.646s OK (skipped=9) SUCCESS ``` After patch: ``` $ make test-memleaks ---------------------------------------------------------------------- Ran 99 tests in 1.195s OK (skipped=9) SUCCESS ```
* | Drop Python 2.6 support (#2099)Hugo van Kemenade2022-04-161-2/+2
| | | | | | Signed-off-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
* | give CREDITS for #1053Giampaolo Rodola2022-04-151-0/+1
|/ | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* OpenBSD: add support for CPU frequency (#2057)Giampaolo Rodola2022-01-161-0/+1
|
* [Linux]: increase `read(2)` buffer size when reading /proc files lines (#2054)Giampaolo Rodola2022-01-151-0/+8
| | | This should help having more consistent results.
* bump up ver + strip() some cat() resultsGiampaolo Rodola2022-01-081-2/+4
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* fix #2048: str(psutil.Error) raise AttributeErrorGiampaolo Rodola2022-01-071-0/+2
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
* fix #2049: [Linux] cpu_freq returns current value in GHz but min/max in MHzGiampaolo Rodola2022-01-071-0/+8
| | | | Signed-off-by: Giampaolo Rodola <g.rodola@gmail.com>
View Lorry Controller Status