Can't compile on Windows #1
Comments
|
From billiej...@gmail.com on January 13, 2009 10:38:12 Labels: Component-Setup OpSys-Windows |
|
From billiej...@gmail.com on January 22, 2009 07:40:37 Status: Fixed |
|
From billiej...@gmail.com on January 27, 2009 09:53:27 Labels: Milestone-0.1.0 |
|
From g.rodola on March 02, 2013 03:35:03 |
This was referenced May 23, 2014
Closed
giampaolo
changed the title
kill_process':
psutil/_psutil_mswindows.c:186: error: hProcess' undeclared (first use in this
function)
psutil/_psutil_mswindows.c:186: error: (Each undeclared identifier is
reported o
nly once
psutil/_psutil_mswindows.c:186: error: for each function it appears in.)
psutil/_psutil_mswindows.c:186: error: false' undeclared (first use in
this fun
ction)
psutil/_psutil_mswindows.c:186: error: PID' undeclared (first use in this
funct
ion)
psutil/_psutil_mswindows.c:199: warning: passing arg 1 of Py_BuildValue' makes
pointer from integer without a cast
psutil/_psutil_mswindows.c: In function SetSeDebug':
psutil/_psutil_mswindows.c:237: error: initializer element is not constant
psutil/_psutil_mswindows.c:237: error: (near initialization for
PsutilMethods[0
].ml_meth')
psutil/_psutil_mswindows.c:238: error: initializer element is not constant
psutil/_psutil_mswindows.c:238: error: (near initialization for
PsutilMethods[0
]')
psutil/_psutil_mswindows.c:239: error: initializer element is not constant
psutil/_psutil_mswindows.c:239: error: (near initialization for
PsutilMethods[1
].ml_meth')
psutil/_psutil_mswindows.c:240: error: initializer element is not constant
psutil/_psutil_mswindows.c:240: error: (near initialization for
PsutilMethods[1
]')
psutil/_psutil_mswindows.c:241: error: initializer element is not constant
psutil/_psutil_mswindows.c:241: error: (near initialization for
PsutilMethods[2
].ml_meth')
psutil/_psutil_mswindows.c:242: error: initializer element is not constant
psutil/_psutil_mswindows.c:242: error: (near initialization for
PsutilMethods[2
]')
psutil/_psutil_mswindows.c:243: error: initializer element is not constant
psutil/_psutil_mswindows.c:243: error: (near initialization for
`PsutilMethods[3
]')
psutil/_psutil_mswindows.c:251: error: syntax error at end of input
error: command 'gcc' failed with exit status 1
_Original issue: http://code.google.com/p/psutil/issues/detail?id=1_
giampaolo
changed the title
kill_process':
psutil/_psutil_mswindows.c:186: error: hProcess' undeclared (first use in this
function)
psutil/_psutil_mswindows.c:186: error: (Each undeclared identifier is
reported o
nly once
psutil/_psutil_mswindows.c:186: error: for each function it appears in.)
psutil/_ps
albrycht
pushed a commit
to albrycht/psutil
that referenced
this issue
Aug 9, 2018
giampaolo
added a commit
that referenced
this issue
May 12, 2020
Preamble ======= We have a [memory leak test suite](https://github.com/giampaolo/psutil/blob/e1ea2bccf8aea404dca0f79398f36f37217c45f6/psutil/tests/__init__.py#L897), which calls a function many times and fails if the process memory increased. We do this in order to detect missing `free()` or `Py_DECREF` calls in the C modules. When we do, then we have a memory leak. The problem ========== A problem we've been having for probably over 10 years, is the false positives. That's because the memory fluctuates. Sometimes it may increase (or even decrease!) due to how the OS handles memory, the Python's garbage collector, the fact that RSS is an approximation and who knows what else. So thus far we tried to compensate that by using the following logic: - warmup (call fun 10 times) - call the function many times (1000) - if memory increased before/after calling function 1000 times, then keep calling it for another 3 secs - if it still increased at all (> 0) then fail This logic didn't really solve the problem, as we still had occasional false positives, especially lately on FreeBSD. The solution ========= This PR changes the internal algorithm so that in case of failure (mem > 0 after calling fun() N times) we retry the test for up to 5 times, increasing N (repetitions) each time, so we consider it a failure only if the memory **keeps increasing** between runs. So for instance, here's a legitimate failure: ``` psutil.tests.test_memory_leaks.TestModuleFunctionsLeaks.test_disk_partitions ... Run #1: extra-mem=696.0K, per-call=3.5K, calls=200 Run #2: extra-mem=1.4M, per-call=3.5K, calls=400 Run #3: extra-mem=2.1M, per-call=3.5K, calls=600 Run #4: extra-mem=2.7M, per-call=3.5K, calls=800 Run #5: extra-mem=3.4M, per-call=3.5K, calls=1000 FAIL ``` If, on the other hand, the memory increased on one run (say 200 calls) but decreased on the next run (say 400 calls), then it clearly means it's a false positive, because memory consumption may be > 0 on second run, but if it's lower than the previous run with less repetitions, then it cannot possibly represent a leak (just a fluctuation): ``` psutil.tests.test_memory_leaks.TestModuleFunctionsLeaks.test_net_connections ... Run #1: extra-mem=568.0K, per-call=2.8K, calls=200 Run #2: extra-mem=24.0K, per-call=61.4B, calls=400 OK ``` Note about mallinfo() ================ Aka #1275. `mallinfo()` on Linux is supposed to provide memory metrics about how many bytes gets allocated on the heap by `malloc()`, so it's supposed to be way more precise than RSS and also [USS](http://grodola.blogspot.com/2016/02/psutil-4-real-process-memory-and-environ.html). In another branch were I exposed it, I verified that fluctuations still occur even when using `mallinfo()` though, despite less often. So that means even `mallinfo()` would not grant 100% stability.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From billiej...@gmail.com on January 13, 2009 19:33:56
Original issue: http://code.google.com/p/psutil/issues/detail?id=1
The text was updated successfully, but these errors were encountered: