I wonder what is the unit for reporting a memory usage returned by vtkPVMemoryUseInformation.GetProcMemoryUse (reference)? Is it a bit, byte, kilobyte? Where can I find this in the documentation?
Update 1
I'm calling the mentioned function from a Python-script with servermanager.vtkPVMemoryUseInformation().GetProcMemoryUse(<index>). We don't have size_t in Python, right? The main question is how can I convert the value into a human-readable value like MB or GB returned by a function call?
This method internally uses vtksys::SystemInformation, which returns system RAM used in units of KiB.
https://github.com/Kitware/VTK/blob/master/Utilities/KWSys/vtksys/SystemInformation.hxx.in
The doc should be improved here.
Related
I am trying to reproduc a problem .
My c code giving SIGABRT , i traced it back to this line number :3174
https://elixir.bootlin.com/glibc/glibc-2.27/source/malloc/malloc.c
/* Little security check which won't hurt performance: the allocator
never wrapps around at the end of the address space. Therefore
we can exclude some size values which might appear here by
accident or by "design" from some intruder. We need to bypass
this check for dumped fake mmap chunks from the old main arena
because the new malloc may provide additional alignment. */
if ((__builtin_expect ((uintptr_t) oldp > (uintptr_t) -oldsize, 0)
|| __builtin_expect (misaligned_chunk (oldp), 0))
&& !DUMPED_MAIN_ARENA_CHUNK (oldp))
malloc_printerr ("realloc(): invalid pointer");
My understanding is that when i call calloc function memory get allocated when I call realloc function and try to increase memory area ,heap is not available for some reason giving SIGABRT
My another question is, How can I limit the heap area to some bytes say, 10 bytes to replicate the problem. In stackoverflow RSLIMIT and srlimit is mentioned but no sample code is mentioned. Can you provide sample code where heap size is 10 Bytes ?
How can I limit the heap area to some bytes say, 10 bytes
Can you provide sample code where heap size is 10 Bytes ?
From How to limit heap size for a c code in linux , you could do:
You could use (inside your program) setrlimit(2), probably with RLIMIT_AS (as cited by Ouah's answer).
#include <sys/resource.h>
int main() {
setrlimit(RLIMIT_AS, &(struct rlimit){10,10});
}
Better yet, make your shell do it. With bash it is the ulimit builtin.
$ ulimit -v 10
$ ./your_program.out
to replicate the problem
Most probably, limiting heap size will result in a different problem related to heap size limit. Most probably it is unrelated, and will not help you to debug the problem. Instead, I would suggest to research address sanitizer and valgrind.
Is there a way to get the occupied memory size in bytes of BigInt numbers?
let a = BigInt(99999n)
console.log(a.length) // yield undefined
Thanks
V8 developer here. There is generally no way to determine the occupied memory size of an object, and BigInts are no exception. Why do you want to access it?
As far as the internal implementation in V8 is concerned, a BigInt has a small object header (currently two pointer sizes; this might change over time), and then a bit for every bit of the BigInt, rounded up to multiples of a pointer size. 99999 is a 17-bit number, so in your example let a = 99999n ("BigInt(99999n)" is superfluous!), the allocated BigInt will consume (2 + Math.ceil(17/64)) * 64 bits === 24 bytes on a 64-bit system.
It may or may not make sense to add length-related properties or methods (.bitLength?) to BigInts in the future. If you have a use case, I suggest you file an issue at https://github.com/tc39/proposal-bigint/issues so that it can be discussed.
I learned that a reference takes 64 bits :
That is, a referential structure will typically use 64-bits for the memory address stored in the array, on top of whatever number of bits are used to represent the object that is considered the element.
How could I see it in action?
In [75]: patients = ["trump", "Trump", "trumP"]
In [76]: id(patients[1])
Out[76]: 4529777048
In [77]: math.log2(4529777048)
Out[77]: 32.076792897710234
It's 2**32 rather than 2**64.
With math.log2(id(obj)) you ask "2 raised to what power gives us the address of obj in the memory?".
This is not how id() works. id() gives you a constant and unique value for every object. In CPython this is the address of the object in the memory.
On 64 bit systems it makes sense to store this address in a 64-bit variable since you would not be able to cover the full address-space with a 32 bit variable.
However a 64 bit reference does not mean, that every object has the address of 2**64. As of 2018 this would not even be possible since our x86_64 pcs have just a 48-bit address space. That the id of your first patient was near 2**32 is (mostly) coincidence.
id will return the address in memory. So, this is not what you are looking for.
Typically a way to get the size in memory of something in Python is using sys.getsizeof(). However, this will return the size of the object. You are interested in the size of the reference to that object.
You can however still calculate this more or less as follows: 8 * struct.calcsize("P"). This will basically reveal if you are on a 32-bit or 64-bit system, and therefore you know what the size of a reference is. But really calculating it by inspecting a reference, I don't know if that is possible.
doing a graphic performance test with CETK (direct draw performance, gdi performance).
Can someone explain how to interpret the test results?
In detail, what do Rgn Count, SampleCount, Min, Max, Std Deviation etc. mean?
Is there some documentation on these available?
Thanks in advance.
Regards, Timm
Here, some example results:
Rgn Count=0
SampleCount=10
Min=0.000000
Max=1000.00000
Mean=700.000000
Std Deviation=577.350269
CV%=82.478610
I hope you are familiar with Filters and Pins.
Sample Count:
When a pin delivers media data to another pin, it does not pass a direct pointer to the memory buffer. Instead, it delivers a pointer to a COM object that manages the memory. This object, called a media sample. An allocator creates a finite pool of samples. The allocator uses reference counting to keep track of the samples. The GetBuffer method returns a sample with a reference count of 1. If the reference count goes to zero, the sample goes back into the allocator's pool, where it can be used in the next GetBuffer call. This is somewhat similar to counting semaphores. While a filter is using a buffer, it holds reference count on the sample. The allocator uses the reference count to determine when it can re-use the buffer. This prevents a filter from overwriting a buffer that another filter is still using. A sample does not return to the allocator's pool of available samples until every filter has released it.
Standard Deviation:
The number of times the benchmark engine samples a particular test case depends on the standard deviation of an initial sample.
I'm not sure about the remaining terms. Maybe, this link could shed some light.
I have a curious memory leak, it seems that the library function to_unbounded_string is leaking!
Code snippets:
procedure Parse (Str : in String;
... do stuff...
declare
New_Element : constant Ada.Strings.Unbounded.Unbounded_String :=
Ada.Strings.Unbounded.To_Unbounded_String (Str); -- this leaks
begin
valgrind output:
==6009== 10,276 bytes in 1 blocks are possibly lost in loss record 153 of 153
==6009== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==6009== by 0x42703B8: __gnat_malloc (in /usr/lib/libgnat-4.4.so.1)
==6009== by 0x4269480: system__secondary_stack__ss_allocate (in /usr/lib/libgnat-4.4.so.1)
==6009== by 0x414929B: ada__strings__unbounded__to_unbounded_string (in /usr/lib/libgnat-4.4.so.1)
==6009== by 0x80F8AD4: syntax__parser__dash_parser__parseXn (token_parser_g.adb:35)
Where token_parser_g.adb:35 is listed above as the "-- this leaks" line.
Other info: Gnatmake version 4.4.5. gcc version 4.4 valgrind version valgrind-3.6.0.SVN-Debian, valgrind options -v --leak-check=full --read-var-info=yes --show-reachable=no
Any help or insights appreciated,
NWS.
Valgrind clearly says that there is possibly a memory leak. It doesn't necessarily mean there is one. For example, if first call to that function allocates a pool of memory that is re-used during the life time of the program but is never freed, Valgrind will report it as a possible memory leak, even though it is not, as this is a common practice and memory will be returned to OS upon process termination.
Now, if you think that there is a memory leak for real, call this function in a loop, and see it memory continues to grow. If it does - file a bug report or even better, try to find and fix the leak and send a patch along with a bug report.
Hope it helps.
Was trying to keep this to comments, but what I was saying got too long and started to need formatting.
In Ada string objects are generally assumed to be perfectly-sized. The language provies functions to return the size and bounds of any string. Because of this, string handling in Ada is very different than C, and in fact more resembles how you'd do it in a functional language like Lisp.
But the basic principle is that, except in some very unusual situations, if you find yourself using Ada.Strings.Unbounded, you are going about things the wrong way.
The one case where you really can't get around using a variable-length string (or perhaps a buffer with a separate valid_length variable), is when reading strings as input from some external source. As you say, your parsing example is such a situation.
However, even here you should only have that situation on the initial buffer. Your call to your Parse routine should look something like this:
Ada.Text_IO.Get_Line (Buffer, Buffer_Len);
Parse (Buffer(Buffer'first..Buffer'first + Buffer_Len - 1));
Now inside the Parse routine you have a perfectly-sized constant Ada string to work with. If for some reason you need to pull out a subslice, you would do the following:
... --// Code to find start and end indices of my subslice
New_Element : constant String := Str(Element_Start...Element_End);
If you don't actually need to make a copy of that data for some reason though, you are better off just finding Element_Start and Element_End and working with a slice of the original string buffer. Eg:
if Str(Element_Start..Element_End) = "MyToken" then
I know this doesn't answer your question about Ada.Strings.Unbounded possibly leaking. But even if it doesn't leak, that code is relatively wasteful of machine resources (CPU and memory), and probably shouldn't be used for string manipulation unless you really need it.
Are bound[ed] strings scoped?
Expanding on #T.E.D.'s comments, Ada.Strings.Bounded "objects should not be implemented by implicit pointers and dynamic allocation." Instead, the maximum size is fixed when the generic in instantiated. As an implmentation detail, GNAT uses a discriminant to specify the maximum size of the string and a record to store the current size & contents.
In contrast, Ada.Strings.Unbounded requires that "No storage associated with an Unbounded_String object shall be lost upon assignment or scope exit." As an implmentation detail, GNAT uses a buffered implementation derived from Ada.Finalization.Controlled. As a result, the memory used by an Unbounded_String may appear to be a leak until the object is finalized, as for example when the code returns to an enclosing scope.