I am receiving the following error when trying to retrieve data using a largish virtual attribute:
Virtual Attribute Error: Virtual field too big.
I have been unable to locate the maximum size allowed for a virtual attribute in the Unidata manuals. I am using Unidata 7.2, ECLTYPE Pick.
If I remember correctly I believe you will need to increase the size of the UDT environment variable VFIELDSIZE to accomodate the attribute in question. Perhaps set it to 400 and see if the problem still occurs.
Related
I am using the MSIX manager tool to convert a *.msix (an application installer) to a *.vhdx so that it can be mounted in an Azure virtual machine. One of the flags that the tool requires is -vhdSize, which is in megabytes. This has proven to be problematic because I have to guess what the size should be based off the MSIX. I have ran into numerous creation errors due to too small of a vhdSize.
I could set it to an arbitrarily high value in order to get around these failures, but that is not ideal. Alternatively, guessing the correct size is an imprecise science and a chore to do repeatedly.
Is there a way to have the tool dynamically set the vhdSize, or am I stuck guessing a value that is both large enough to accommodate the file, but not too large as to waste disk space? Or, is there a better way to create a *.vhdx file?
https://techcommunity.microsoft.com/t5/windows-virtual-desktop/simplify-msix-image-creation-with-the-msixmgr-tool/m-p/2118585
There is an MSIX Hero app that could select a size for you, it will automatically check how big the uncompressed files are, add an extra buffer for safety (currently double the original size), and round it to the next 10MB. Reference from https://msixhero.net/documentation/creating-vhd-for-msix-app-attach/
I'm new to the linux kernel and trying to alter the current buddy allocator for Linux and for that I'm trying to find where the bitmap is assigned to each free_area for each zone that the buddy allocator uses while assigning blocks.
From what I understand is that the zone->free_area[order] points to list of blocks of size 2order. Now I'm assuming such a mapping as it is mathematical may be hidden in a macro/function concealed some shift operation.
What I wish to do is find that and alter it to change the size of blocks for each free_area (to my knowledge there are 10 of those)
Any pointer on where I should be looking is appreciated.
Adding a picture for clarity - What I really need his where are these bitmaps defined to be in the size of 2order.
PS: Also most the documentation I've found on this related to the linux kernel 2 and a lots of structuring has changed since but although by looking at the code it seems like the core logic is still intact and that's why it has been of some help on where to look in not where it is.
I have been reading through some ARM code in order to try and understand what exactly the cpu_domain field inside the struct thread_info represents. In an attempt to understand how it is used, I looked through the places where the variable is referenced. I am trying to understand the following :-
Why is the field present in thread_info? I can see that when a context switch happens, the value is set / read, but why? What purpose does the field serve?
I had a look at the function modify_domain that seems to retrieve the domain value and set it in coprocessor CP15, c3. But where is this used? Any system call that takes in addresses verifies it against addr_limit, and page tables have the supervisor bit to check if reads/writes are allowed from userspace. So where do ARM domains come into the picture?
I have a driver that mapping system RAM memory by using function remap_pfn_range. However recently I encounter a following problem when writing to the mapping memory region:
BUG: unable to handle kernel
mydriver: Corrupted page table at address ffff88117ff72000
Could anyone explain for me what does exactly the "corrupted page table at address" means?
Thank you,
The page table is the part of the OS that keeps track of pages of memory and where they are (disk, RAM, etc.)
Somewhere there is a pointer to this page table <0xffff88117ff72000>, and it is either messed up or the place it points to is messed up. Either way, the error message indicates the page table isn't understandable at this point.
I have a slider used to change the font size of the text in a UITextView. Analyzer and Leaks report no memory leak. However, the memory grows each time I change the font size by moving the slider. Eventually the app gets an out of memory warning. The code is:
mainText.font = [UIFont systemFontOfSize:mainSlider.value];
If I replace that code with mainText.font = [UIFont systemFontOfSize:40.0];, memory stays the same no matter how many times I move the slider. I searched this and many other sites looking for info on a possible UIFont bug. No success. I see people using the same code I am using and not mentioning increasing memory. Please help.
There is probably a font cache in place to avoid regenerating the same fonts over and over again (a bit like [UIImage imageNamed:#""])
It is not explicitly stated in the docs but reading
You do not create UIFont objects using
the alloc and init methods. Instead,
you use class methods of UIFont to
look up and retrieve the desired font
object. These methods check for an
existing font object with the
specified characteristics and return
it if it exists. Otherwise, they
create a new font object based on the
desired font characteristics.
could make one believe there is a cache
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIFont_Class/Reference/Reference.html
Also, what are you calling an "out of memory warning"? I presume it's just a "memory warning level=1", and not an application crash because of out-of-memory?