Rust error allocating memory

Summary

While trying to build Firefox 59.0.2 for i686 under a Manjaro Linux (Arch-like) Docker-based build container, rustc panics with «Cannot allocate memory» while compiling the gkrust crate.

I’m reporting because the backtrace asked me to.

Details

On first look this would appear to be rustc trying to allocate more than ~3GB RAM during the LTO step as seen https://bugzilla.mozilla.org/show_bug.cgi?id=1417268#c13, and a similar thing last occurred with rustc 1.22 (https://bbs.archlinux32.org/viewtopic.php?id=643).

Monitoring RAM usage during the failing compilation step appears to show it remaining fairly constant at ~1.3GB RES for a «long» period (~50% time before failure), jumping to ~1.5GB RES, then jumping again to 1.7GB and 2.0GB (~80% TBF), before finally (~95% TBF) rapidly increasing in ~100MB steps and panicking somewhere around ~3GB RES.

I am able to successfully build 64-bit Firefox 59.0.2, as well as both 32- and 64-bit Firefox ESR 52.7.3 with the same build container setup, so it looks to be something specific between i686 rustc and FF 59’s use of the gkrust crate.

I have not set any resource limits for Docker.

Steps which might reproduce

git clone https://github.com/jonathonf/manjaro-32-build.git
mkdir firefox && cd $_
curl -L -f "https://git.archlinux.org/svntogit/packages.git/snapshot/packages/firefox.tar.gz" -o - | bsdtar --strip-components 3 --include="*/firefox/trunk/" -xvf -
../manjaro-32-build/run.sh

Failing command with flags

/usr/bin/rustc —crate-name gkrust lib.rs —color always —crate-type staticlib —emit=dep-info,link -C opt-level=2 -C panic=abort -C lto —cfg feature=»bindgen» —cfg feature=»cubeb-remoting» —cfg feature=»cubeb_pulse_rust» —cfg feature=»gkrust-shared» —cfg feature=»no-static-ideograph-encoder-tables» —cfg feature=»servo» —cfg feature=»simd-accel» -C metadata=651646389c08113e -C extra-filename=-651646389c08113e —out-dir /build/src/mozilla-unified/obj-i686-pc-linux-gnu/toolkit/library/i686-unknown-linux-gnu/release/deps —target i686-unknown-linux-gnu -C linker=/build/src/mozilla-unified/build/cargo-linker -L dependency=/build/src/mozilla-unified/obj-i686-pc-linux-gnu/toolkit/library/i686-unknown-linux-gnu/release/deps -L dependency=/build/src/mozilla-unified/obj-i686-pc-linux-gnu/toolkit/library/release/deps —extern gkrust_shared=/build/src/mozilla-unified/obj-i686-pc-linux-gnu/toolkit/library/i686-unknown-linux-gnu/release/deps/libgkrust_shared-f2bb0c738944c0f6.rlib -C opt-level=2 -C debuginfo=2

Backtrace

 8:40.67    Compiling gkrust v0.1.0 (file:///build/src/mozilla-unified/toolkit/library/rust)
35:17.52 thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: StringError("Cannot allocate memory") }', libcore/result.rs:945:5
35:17.53 stack backtrace:
35:17.71    0: 0xf747766a - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71    1: 0xf746f0fb - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71    2: 0xf7474224 - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71    3: 0xf7473f4f - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71    4: 0xf74746a1 - std::panicking::rust_panic_with_hook::hb8beb8efb6b91903
35:17.71    5: 0xf7474515 - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71    6: 0xf7474496 - std::panicking::begin_panic_fmt::he4dfe7a67e7c0076
35:17.71    7: 0xf74743fb - rust_begin_unwind
35:17.71    8: 0xf74e226e - core::panicking::panic_fmt::he2c3b98e9730a002
35:17.71    9: 0xf04c7497 - <unknown>
35:17.71   10: 0xf04f5667 - <unknown>
35:17.71   11: 0xf04f4320 - <unknown>
35:17.71   12: 0xf0593809 - <unknown>
35:17.71   13: 0xf05912b1 - <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::join_trans_and_link::hd108c8a9e5d89c4d
35:17.71   14: 0xf762d843 - rustc_driver::driver::compile_input::hd9c20dd67b35c276
35:17.71   15: 0xf764a9b5 - rustc_driver::run_compiler::h2b965134b6c46ea8
35:17.71   16: 0xf756d933 - rust_metadata_rustc_driver_9af17ad1a24b9c2356fb6a6c6e5db9d5
35:17.71   17: 0xf748bdd2 - __rust_maybe_catch_panic
35:17.71   18: 0xf75a7b93 - <unknown>
35:17.71   19: 0xf7482bfa - rust_metadata_std_ae049937c58eac2695c432bfa6d5d39f
35:17.71   20: 0xf5854e55 - start_thread
35:17.71   21: 0xf73366b5 - __GI___clone
35:17.71   22:        0x0 - <unknown>
35:17.75 
35:17.75 error: internal compiler error: unexpected panic
35:17.75 
35:17.75 note: the compiler unexpectedly panicked. this is a bug.
35:17.75 
35:17.75 note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
35:17.75 
35:17.75 note: rustc 1.25.0 running on i686-unknown-linux-gnu
35:17.75 
35:17.94 error: Could not compile `gkrust`.
35:17.94 
35:17.94 To learn more, run the command again with --verbose.
35:17.94 make[4]: *** [/build/src/mozilla-unified/config/rules.mk:972: force-cargo-library-build] Error 101
35:17.94 make[3]: *** [/build/src/mozilla-unified/config/recurse.mk:73: toolkit/library/rust/target] Error 2
35:17.94 make[2]: *** [/build/src/mozilla-unified/config/recurse.mk:33: compile] Error 2
35:17.94 make[1]: *** [/build/src/mozilla-unified/config/rules.mk:434: default] Error 2
35:17.94 make: *** [client.mk:168: build] Error 2
35:17.97 0 compiler warnings present.
35:18.04 Failed to parse ccache stats output: stats zero time                     Thu Apr  5 15:52:33 2018
35:18.04 Notification center failed: Install notify-send (usually part of the libnotify package) to get a notification when the build finishes.

rustc --version --verbose

rustc 1.25.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: i686-unknown-linux-gnu
release: 1.25.0
LLVM version: 6.0

Packaging files

rustc: https://www.archlinux.org/packages/community/x86_64/rust/
firefox: https://www.archlinux.org/packages/extra/x86_64/firefox/

This post adds support for heap allocation to our kernel. First, it gives an introduction to dynamic memory and shows how the borrow checker prevents common allocation errors. It then implements the basic allocation interface of Rust, creates a heap memory region, and sets up an allocator crate. At the end of this post, all the allocation and collection types of the built-in alloc crate will be available to our kernel.

This blog is openly developed on GitHub. If you have any problems or questions, please open an issue there. You can also leave comments at the bottom. The complete source code for this post can be found in the post-10 branch.

Table of Contents

• Local and Static Variables
  • Local Variables
  • Static Variables
• Dynamic Memory
  • Common Errors
  • Allocations in Rust
  • Use Cases
• The Allocator Interface
  • The GlobalAlloc Trait
  • A DummyAllocator
  • The #[global_allocator] Attribute
  • The #[alloc_error_handler] Attribute
• Creating a Kernel Heap

• Using an Allocator Crate

• Adding a Test

• Summary

• What’s next?

🔗Local and Static Variables

We currently use two types of variables in our kernel: local variables and static variables. Local variables are stored on the call stack and are only valid until the surrounding function returns. Static variables are stored at a fixed memory location and always live for the complete lifetime of the program.

🔗Local Variables

Local variables are stored on the call stack, which is a stack data structure that supports push and pop operations. On each function entry, the parameters, the return address, and the local variables of the called function are pushed by the compiler:

The above example shows the call stack after the outer function called the inner function. We see that the call stack contains the local variables of outer first. On the inner call, the parameter 1 and the return address for the function were pushed. Then control was transferred to inner, which pushed its local variables.

After the inner function returns, its part of the call stack is popped again and only the local variables of outer remain:

We see that the local variables of inner only live until the function returns. The Rust compiler enforces these lifetimes and throws an error when we use a value for too long, for example when we try to return a reference to a local variable:

fn inner(i: usize) -> &'static u32 {
    let z = [1, 2, 3];
    &z[i]
}

(run the example on the playground)

While returning a reference makes no sense in this example, there are cases where we want a variable to live longer than the function. We already saw such a case in our kernel when we tried to load an interrupt descriptor table and had to use a static variable to extend the lifetime.

🔗Static Variables

Static variables are stored at a fixed memory location separate from the stack. This memory location is assigned at compile time by the linker and encoded in the executable. Statics live for the complete runtime of the program, so they have the 'static lifetime and can always be referenced from local variables:

When the inner function returns in the above example, its part of the call stack is destroyed. The static variables live in a separate memory range that is never destroyed, so the &Z[1] reference is still valid after the return.

Apart from the 'static lifetime, static variables also have the useful property that their location is known at compile time, so that no reference is needed for accessing them. We utilized that property for our println macro: By using a static Writer internally, there is no &mut Writer reference needed to invoke the macro, which is very useful in exception handlers, where we don’t have access to any additional variables.

However, this property of static variables brings a crucial drawback: they are read-only by default. Rust enforces this because a data race would occur if, e.g., two threads modified a static variable at the same time. The only way to modify a static variable is to encapsulate it in a Mutex type, which ensures that only a single &mut reference exists at any point in time. We already used a Mutex for our static VGA buffer Writer.

🔗Dynamic Memory

Local and static variables are already very powerful together and enable most use cases. However, we saw that they both have their limitations:

• Local variables only live until the end of the surrounding function or block. This is because they live on the call stack and are destroyed after the surrounding function returns.
• Static variables always live for the complete runtime of the program, so there is no way to reclaim and reuse their memory when they’re no longer needed. Also, they have unclear ownership semantics and are accessible from all functions, so they need to be protected by a Mutex when we want to modify them.

Another limitation of local and static variables is that they have a fixed size. So they can’t store a collection that dynamically grows when more elements are added. (There are proposals for unsized rvalues in Rust that would allow dynamically sized local variables, but they only work in some specific cases.)

To circumvent these drawbacks, programming languages often support a third memory region for storing variables called the heap. The heap supports dynamic memory allocation at runtime through two functions called allocate and deallocate. It works in the following way: The allocate function returns a free chunk of memory of the specified size that can be used to store a variable. This variable then lives until it is freed by calling the deallocate function with a reference to the variable.

Let’s go through an example:

Here the inner function uses heap memory instead of static variables for storing z. It first allocates a memory block of the required size, which returns a *mut u32 raw pointer. It then uses the ptr::write method to write the array [1,2,3] to it. In the last step, it uses the offset function to calculate a pointer to the i-th element and then returns it. (Note that we omitted some required casts and unsafe blocks in this example function for brevity.)

The allocated memory lives until it is explicitly freed through a call to deallocate. Thus, the returned pointer is still valid even after inner returned and its part of the call stack was destroyed. The advantage of using heap memory compared to static memory is that the memory can be reused after it is freed, which we do through the deallocate call in outer. After that call, the situation looks like this:

We see that the z[1] slot is free again and can be reused for the next allocate call. However, we also see that z[0] and z[2] are never freed because we never deallocate them. Such a bug is called a memory leak and is often the cause of excessive memory consumption of programs (just imagine what happens when we call inner repeatedly in a loop). This might seem bad, but there are much more dangerous types of bugs that can happen with dynamic allocation.

🔗Common Errors

Apart from memory leaks, which are unfortunate but don’t make the program vulnerable to attackers, there are two common types of bugs with more severe consequences:

• When we accidentally continue to use a variable after calling deallocate on it, we have a so-called use-after-free vulnerability. Such a bug causes undefined behavior and can often be exploited by attackers to execute arbitrary code.
• When we accidentally free a variable twice, we have a double-free vulnerability. This is problematic because it might free a different allocation that was allocated in the same spot after the first deallocate call. Thus, it can lead to a use-after-free vulnerability again.

These types of vulnerabilities are commonly known, so one might expect that people have learned how to avoid them by now. But no, such vulnerabilities are still regularly found, for example this use-after-free vulnerability in Linux (2019), that allowed arbitrary code execution. A web search like use-after-free linux {current year} will probably always yield results. This shows that even the best programmers are not always able to correctly handle dynamic memory in complex projects.

To avoid these issues, many languages, such as Java or Python, manage dynamic memory automatically using a technique called garbage collection. The idea is that the programmer never invokes deallocate manually. Instead, the program is regularly paused and scanned for unused heap variables, which are then automatically deallocated. Thus, the above vulnerabilities can never occur. The drawbacks are the performance overhead of the regular scan and the probably long pause times.

Rust takes a different approach to the problem: It uses a concept called ownership that is able to check the correctness of dynamic memory operations at compile time. Thus, no garbage collection is needed to avoid the mentioned vulnerabilities, which means that there is no performance overhead. Another advantage of this approach is that the programmer still has fine-grained control over the use of dynamic memory, just like with C or C++.

🔗Allocations in Rust

Instead of letting the programmer manually call allocate and deallocate, the Rust standard library provides abstraction types that call these functions implicitly. The most important type is Box, which is an abstraction for a heap-allocated value. It provides a Box::new constructor function that takes a value, calls allocate with the size of the value, and then moves the value to the newly allocated slot on the heap. To free the heap memory again, the Box type implements the Drop trait to call deallocate when it goes out of scope:

{
    let z = Box::new([1,2,3]);
    […]
} // z goes out of scope and `deallocate` is called

This pattern has the strange name resource acquisition is initialization (or RAII for short). It originated in C++, where it is used to implement a similar abstraction type called std::unique_ptr.

Such a type alone does not suffice to prevent all use-after-free bugs since programmers can still hold on to references after the Box goes out of scope and the corresponding heap memory slot is deallocated:

let x = {
    let z = Box::new([1,2,3]);
    &z[1]
}; // z goes out of scope and `deallocate` is called
println!("{}", x);

This is where Rust’s ownership comes in. It assigns an abstract lifetime to each reference, which is the scope in which the reference is valid. In the above example, the x reference is taken from the z array, so it becomes invalid after z goes out of scope. When you run the above example on the playground you see that the Rust compiler indeed throws an error:

error[E0597]: `z[_]` does not live long enough
 --> src/main.rs:4:9
  |
2 |     let x = {
  |         - borrow later stored here
3 |         let z = Box::new([1,2,3]);
4 |         &z[1]
  |         ^^^^^ borrowed value does not live long enough
5 |     }; // z goes out of scope and `deallocate` is called
  |     - `z[_]` dropped here while still borrowed

The terminology can be a bit confusing at first. Taking a reference to a value is called borrowing the value since it’s similar to a borrow in real life: You have temporary access to an object but need to return it sometime, and you must not destroy it. By checking that all borrows end before an object is destroyed, the Rust compiler can guarantee that no use-after-free situation can occur.

Rust’s ownership system goes even further, preventing not only use-after-free bugs but also providing complete memory safety, as garbage collected languages like Java or Python do. Additionally, it guarantees thread safety and is thus even safer than those languages in multi-threaded code. And most importantly, all these checks happen at compile time, so there is no runtime overhead compared to hand-written memory management in C.

🔗Use Cases

We now know the basics of dynamic memory allocation in Rust, but when should we use it? We’ve come really far with our kernel without dynamic memory allocation, so why do we need it now?

First, dynamic memory allocation always comes with a bit of performance overhead since we need to find a free slot on the heap for every allocation. For this reason, local variables are generally preferable, especially in performance-sensitive kernel code. However, there are cases where dynamic memory allocation is the best choice.

As a basic rule, dynamic memory is required for variables that have a dynamic lifetime or a variable size. The most important type with a dynamic lifetime is Rc, which counts the references to its wrapped value and deallocates it after all references have gone out of scope. Examples for types with a variable size are Vec, String, and other collection types that dynamically grow when more elements are added. These types work by allocating a larger amount of memory when they become full, copying all elements over, and then deallocating the old allocation.

For our kernel, we will mostly need the collection types, for example, to store a list of active tasks when implementing multitasking in future posts.

🔗The Allocator Interface

The first step in implementing a heap allocator is to add a dependency on the built-in alloc crate. Like the core crate, it is a subset of the standard library that additionally contains the allocation and collection types. To add the dependency on alloc, we add the following to our lib.rs:

// in src/lib.rs

extern crate alloc;

Contrary to normal dependencies, we don’t need to modify the Cargo.toml. The reason is that the alloc crate ships with the Rust compiler as part of the standard library, so the compiler already knows about the crate. By adding this extern crate statement, we specify that the compiler should try to include it. (Historically, all dependencies needed an extern crate statement, which is now optional).

Since we are compiling for a custom target, we can’t use the precompiled version of alloc that is shipped with the Rust installation. Instead, we have to tell cargo to recompile the crate from source. We can do that by adding it to the unstable.build-std array in our .cargo/config.toml file:

# in .cargo/config.toml

[unstable]
build-std = ["core", "compiler_builtins", "alloc"]

Now the compiler will recompile and include the alloc crate in our kernel.

The reason that the alloc crate is disabled by default in #[no_std] crates is that it has additional requirements. When we try to compile our project now, we will see these requirements as errors:

error: no global memory allocator found but one is required; link to std or add
       #[global_allocator] to a static item that implements the GlobalAlloc trait.

error: `#[alloc_error_handler]` function required, but not found

The first error occurs because the alloc crate requires a heap allocator, which is an object that provides the allocate and deallocate functions. In Rust, heap allocators are described by the GlobalAlloc trait, which is mentioned in the error message. To set the heap allocator for the crate, the #[global_allocator] attribute must be applied to a static variable that implements the GlobalAlloc trait.

The second error occurs because calls to allocate can fail, most commonly when there is no more memory available. Our program must be able to react to this case, which is what the #[alloc_error_handler] function is for.

We will describe these traits and attributes in detail in the following sections.

🔗The GlobalAlloc Trait

The GlobalAlloc trait defines the functions that a heap allocator must provide. The trait is special because it is almost never used directly by the programmer. Instead, the compiler will automatically insert the appropriate calls to the trait methods when using the allocation and collection types of alloc.

Since we will need to implement the trait for all our allocator types, it is worth taking a closer look at its declaration:

pub unsafe trait GlobalAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8;
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout);

    unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { ... }
    unsafe fn realloc(
        &self,
        ptr: *mut u8,
        layout: Layout,
        new_size: usize
    ) -> *mut u8 { ... }
}

It defines the two required methods alloc and dealloc, which correspond to the allocate and deallocate functions we used in our examples:

• The alloc method takes a Layout instance as an argument, which describes the desired size and alignment that the allocated memory should have. It returns a raw pointer to the first byte of the allocated memory block. Instead of an explicit error value, the alloc method returns a null pointer to signal an allocation error. This is a bit non-idiomatic, but it has the advantage that wrapping existing system allocators is easy since they use the same convention.
• The dealloc method is the counterpart and is responsible for freeing a memory block again. It receives two arguments: the pointer returned by alloc and the Layout that was used for the allocation.

The trait additionally defines the two methods alloc_zeroed and realloc with default implementations:

• The alloc_zeroed method is equivalent to calling alloc and then setting the allocated memory block to zero, which is exactly what the provided default implementation does. An allocator implementation can override the default implementations with a more efficient custom implementation if possible.
• The realloc method allows to grow or shrink an allocation. The default implementation allocates a new memory block with the desired size and copies over all the content from the previous allocation. Again, an allocator implementation can probably provide a more efficient implementation of this method, for example by growing/shrinking the allocation in-place if possible.

🔗Unsafety

One thing to notice is that both the trait itself and all trait methods are declared as unsafe:

• The reason for declaring the trait as unsafe is that the programmer must guarantee that the trait implementation for an allocator type is correct. For example, the alloc method must never return a memory block that is already used somewhere else because this would cause undefined behavior.
• Similarly, the reason that the methods are unsafe is that the caller must ensure various invariants when calling the methods, for example, that the Layout passed to alloc specifies a non-zero size. This is not really relevant in practice since the methods are normally called directly by the compiler, which ensures that the requirements are met.

🔗A DummyAllocator

Now that we know what an allocator type should provide, we can create a simple dummy allocator. For that, we create a new allocator module:

// in src/lib.rs

pub mod allocator;

Our dummy allocator does the absolute minimum to implement the trait and always returns an error when alloc is called. It looks like this:

// in src/allocator.rs

use alloc::alloc::{GlobalAlloc, Layout};
use core::ptr::null_mut;

pub struct Dummy;

unsafe impl GlobalAlloc for Dummy {
    unsafe fn alloc(&self, _layout: Layout) -> *mut u8 {
        null_mut()
    }

    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
        panic!("dealloc should be never called")
    }
}

The struct does not need any fields, so we create it as a zero-sized type. As mentioned above, we always return the null pointer from alloc, which corresponds to an allocation error. Since the allocator never returns any memory, a call to dealloc should never occur. For this reason, we simply panic in the dealloc method. The alloc_zeroed and realloc methods have default implementations, so we don’t need to provide implementations for them.

We now have a simple allocator, but we still have to tell the Rust compiler that it should use this allocator. This is where the #[global_allocator] attribute comes in.

🔗The #[global_allocator] Attribute

The #[global_allocator] attribute tells the Rust compiler which allocator instance it should use as the global heap allocator. The attribute is only applicable to a static that implements the GlobalAlloc trait. Let’s register an instance of our Dummy allocator as the global allocator:

// in src/allocator.rs

#[global_allocator]
static ALLOCATOR: Dummy = Dummy;

Since the Dummy allocator is a zero-sized type, we don’t need to specify any fields in the initialization expression.

When we now try to compile it, the first error should be gone. Let’s fix the remaining second error:

error: `#[alloc_error_handler]` function required, but not found

🔗The #[alloc_error_handler] Attribute

As we learned when discussing the GlobalAlloc trait, the alloc function can signal an allocation error by returning a null pointer. The question is: how should the Rust runtime react to such an allocation failure? This is where the #[alloc_error_handler] attribute comes in. It specifies a function that is called when an allocation error occurs, similar to how our panic handler is called when a panic occurs.

Let’s add such a function to fix the compilation error:

// in src/lib.rs

#![feature(alloc_error_handler)] // at the top of the file

#[alloc_error_handler]
fn alloc_error_handler(layout: alloc::alloc::Layout) -> ! {
    panic!("allocation error: {:?}", layout)
}

The alloc_error_handler function is still unstable, so we need a feature gate to enable it. The function receives a single argument: the Layout instance that was passed to alloc when the allocation failure occurred. There’s nothing we can do to resolve the failure, so we just panic with a message that contains the Layout instance.

With this function, the compilation errors should be fixed. Now we can use the allocation and collection types of alloc. For example, we can use a Box to allocate a value on the heap:

// in src/main.rs

extern crate alloc;

use alloc::boxed::Box;

fn kernel_main(boot_info: &'static BootInfo) -> ! {
    // […] print "Hello World!", call `init`, create `mapper` and `frame_allocator`

    let x = Box::new(41);

    // […] call `test_main` in test mode

    println!("It did not crash!");
    blog_os::hlt_loop();
}

Note that we need to specify the extern crate alloc statement in our main.rs too. This is required because the lib.rs and main.rs parts are treated as separate crates. However, we don’t need to create another #[global_allocator] static because the global allocator applies to all crates in the project. In fact, specifying an additional allocator in another crate would be an error.

When we run the above code, we see that our alloc_error_handler function is called:

The error handler is called because the Box::new function implicitly calls the alloc function of the global allocator. Our dummy allocator always returns a null pointer, so every allocation fails. To fix this, we need to create an allocator that actually returns usable memory.

🔗Creating a Kernel Heap

Before we can create a proper allocator, we first need to create a heap memory region from which the allocator can allocate memory. To do this, we need to define a virtual memory range for the heap region and then map this region to physical frames. See the “Introduction To Paging” post for an overview of virtual memory and page tables.

The first step is to define a virtual memory region for the heap. We can choose any virtual address range that we like, as long as it is not already used for a different memory region. Let’s define it as the memory starting at address 0x_4444_4444_0000 so that we can easily recognize a heap pointer later:

// in src/allocator.rs

pub const HEAP_START: usize = 0x_4444_4444_0000;
pub const HEAP_SIZE: usize = 100 * 1024; // 100 KiB

We set the heap size to 100 KiB for now. If we need more space in the future, we can simply increase it.

If we tried to use this heap region now, a page fault would occur since the virtual memory region is not mapped to physical memory yet. To resolve this, we create an init_heap function that maps the heap pages using the Mapper API that we introduced in the “Paging Implementation” post:

// in src/allocator.rs

use x86_64::{
    structures::paging::{
        mapper::MapToError, FrameAllocator, Mapper, Page, PageTableFlags, Size4KiB,
    },
    VirtAddr,
};

pub fn init_heap(
    mapper: &mut impl Mapper<Size4KiB>,
    frame_allocator: &mut impl FrameAllocator<Size4KiB>,
) -> Result<(), MapToError<Size4KiB>> {
    let page_range = {
        let heap_start = VirtAddr::new(HEAP_START as u64);
        let heap_end = heap_start + HEAP_SIZE - 1u64;
        let heap_start_page = Page::containing_address(heap_start);
        let heap_end_page = Page::containing_address(heap_end);
        Page::range_inclusive(heap_start_page, heap_end_page)
    };

    for page in page_range {
        let frame = frame_allocator
            .allocate_frame()
            .ok_or(MapToError::FrameAllocationFailed)?;
        let flags = PageTableFlags::PRESENT | PageTableFlags::WRITABLE;
        unsafe {
            mapper.map_to(page, frame, flags, frame_allocator)?.flush()
        };
    }

    Ok(())
}

The function takes mutable references to a Mapper and a FrameAllocator instance, both limited to 4 KiB pages by using Size4KiB as the generic parameter. The return value of the function is a Result with the unit type () as the success variant and a MapToError as the error variant, which is the error type returned by the Mapper::map_to method. Reusing the error type makes sense here because the map_to method is the main source of errors in this function.

The implementation can be broken down into two parts:

• Creating the page range:: To create a range of the pages that we want to map, we convert the HEAP_START pointer to a VirtAddr type. Then we calculate the heap end address from it by adding the HEAP_SIZE. We want an inclusive bound (the address of the last byte of the heap), so we subtract 1. Next, we convert the addresses into Page types using the containing_address function. Finally, we create a page range from the start and end pages using the Page::range_inclusive function.

• Mapping the pages: The second step is to map all pages of the page range we just created. For that, we iterate over these pages using a for loop. For each page, we do the following:

  • We allocate a physical frame that the page should be mapped to using the FrameAllocator::allocate_frame method. This method returns None when there are no more frames left. We deal with that case by mapping it to a MapToError::FrameAllocationFailed error through the Option::ok_or method and then applying the question mark operator to return early in the case of an error.

  • We set the required PRESENT flag and the WRITABLE flag for the page. With these flags, both read and write accesses are allowed, which makes sense for heap memory.

  • We use the Mapper::map_to method for creating the mapping in the active page table. The method can fail, so we use the question mark operator again to forward the error to the caller. On success, the method returns a MapperFlush instance that we can use to update the translation lookaside buffer using the flush method.

The final step is to call this function from our kernel_main:

// in src/main.rs

fn kernel_main(boot_info: &'static BootInfo) -> ! {
    use blog_os::allocator; // new import
    use blog_os::memory::{self, BootInfoFrameAllocator};

    println!("Hello World{}", "!");
    blog_os::init();

    let phys_mem_offset = VirtAddr::new(boot_info.physical_memory_offset);
    let mut mapper = unsafe { memory::init(phys_mem_offset) };
    let mut frame_allocator = unsafe {
        BootInfoFrameAllocator::init(&boot_info.memory_map)
    };

    // new
    allocator::init_heap(&mut mapper, &mut frame_allocator)
        .expect("heap initialization failed");

    let x = Box::new(41);

    // […] call `test_main` in test mode

    println!("It did not crash!");
    blog_os::hlt_loop();
}

We show the full function for context here. The only new lines are the blog_os::allocator import and the call to the allocator::init_heap function. In case the init_heap function returns an error, we panic using the Result::expect method since there is currently no sensible way for us to handle this error.

We now have a mapped heap memory region that is ready to be used. The Box::new call still uses our old Dummy allocator, so you will still see the “out of memory” error when you run it. Let’s fix this by using a proper allocator.

🔗Using an Allocator Crate

Since implementing an allocator is somewhat complex, we start by using an external allocator crate. We will learn how to implement our own allocator in the next post.

A simple allocator crate for no_std applications is the linked_list_allocator crate. Its name comes from the fact that it uses a linked list data structure to keep track of deallocated memory regions. See the next post for a more detailed explanation of this approach.

To use the crate, we first need to add a dependency on it in our Cargo.toml:

# in Cargo.toml

[dependencies]
linked_list_allocator = "0.9.0"

Then we can replace our dummy allocator with the allocator provided by the crate:

// in src/allocator.rs

use linked_list_allocator::LockedHeap;

#[global_allocator]
static ALLOCATOR: LockedHeap = LockedHeap::empty();

The struct is named LockedHeap because it uses the spinning_top::Spinlock type for synchronization. This is required because multiple threads could access the ALLOCATOR static at the same time. As always, when using a spinlock or a mutex, we need to be careful to not accidentally cause a deadlock. This means that we shouldn’t perform any allocations in interrupt handlers, since they can run at an arbitrary time and might interrupt an in-progress allocation.

Setting the LockedHeap as global allocator is not enough. The reason is that we use the empty constructor function, which creates an allocator without any backing memory. Like our dummy allocator, it always returns an error on alloc. To fix this, we need to initialize the allocator after creating the heap:

// in src/allocator.rs

pub fn init_heap(
    mapper: &mut impl Mapper<Size4KiB>,
    frame_allocator: &mut impl FrameAllocator<Size4KiB>,
) -> Result<(), MapToError<Size4KiB>> {
    // […] map all heap pages to physical frames

    // new
    unsafe {
        ALLOCATOR.lock().init(HEAP_START, HEAP_SIZE);
    }

    Ok(())
}

We use the lock method on the inner spinlock of the LockedHeap type to get an exclusive reference to the wrapped Heap instance, on which we then call the init method with the heap bounds as arguments. Because the init function already tries to write to the heap memory, we must initialize the heap only after mapping the heap pages.

After initializing the heap, we can now use all allocation and collection types of the built-in alloc crate without error:

// in src/main.rs

use alloc::{boxed::Box, vec, vec::Vec, rc::Rc};

fn kernel_main(boot_info: &'static BootInfo) -> ! {
    // […] initialize interrupts, mapper, frame_allocator, heap

    // allocate a number on the heap
    let heap_value = Box::new(41);
    println!("heap_value at {:p}", heap_value);

    // create a dynamically sized vector
    let mut vec = Vec::new();
    for i in 0..500 {
        vec.push(i);
    }
    println!("vec at {:p}", vec.as_slice());

    // create a reference counted vector -> will be freed when count reaches 0
    let reference_counted = Rc::new(vec![1, 2, 3]);
    let cloned_reference = reference_counted.clone();
    println!("current reference count is {}", Rc::strong_count(&cloned_reference));
    core::mem::drop(reference_counted);
    println!("reference count is {} now", Rc::strong_count(&cloned_reference));

    // […] call `test_main` in test context
    println!("It did not crash!");
    blog_os::hlt_loop();
}

This code example shows some uses of the Box, Vec, and Rc types. For the Box and Vec types, we print the underlying heap pointers using the {:p} formatting specifier. To showcase Rc, we create a reference-counted heap value and use the Rc::strong_count function to print the current reference count before and after dropping an instance (using core::mem::drop).

When we run it, we see the following:

As expected, we see that the Box and Vec values live on the heap, as indicated by the pointer starting with the 0x_4444_4444_* prefix. The reference counted value also behaves as expected, with the reference count being 2 after the clone call, and 1 again after one of the instances was dropped.

The reason that the vector starts at offset 0x800 is not that the boxed value is 0x800 bytes large, but the reallocations that occur when the vector needs to increase its capacity. For example, when the vector’s capacity is 32 and we try to add the next element, the vector allocates a new backing array with a capacity of 64 behind the scenes and copies all elements over. Then it frees the old allocation.

Of course, there are many more allocation and collection types in the alloc crate that we can now all use in our kernel, including:

• the thread-safe reference counted pointer Arc
• the owned string type String and the format! macro
• LinkedList
• the growable ring buffer VecDeque
• the BinaryHeap priority queue
• BTreeMap and BTreeSet

These types will become very useful when we want to implement thread lists, scheduling queues, or support for async/await.

🔗Adding a Test

To ensure that we don’t accidentally break our new allocation code, we should add an integration test for it. We start by creating a new tests/heap_allocation.rs file with the following content:

// in tests/heap_allocation.rs

#![no_std]
#![no_main]
#![feature(custom_test_frameworks)]
#![test_runner(blog_os::test_runner)]
#![reexport_test_harness_main = "test_main"]

extern crate alloc;

use bootloader::{entry_point, BootInfo};
use core::panic::PanicInfo;

entry_point!(main);

fn main(boot_info: &'static BootInfo) -> ! {
    unimplemented!();
}

#[panic_handler]
fn panic(info: &PanicInfo) -> ! {
    blog_os::test_panic_handler(info)
}

We reuse the test_runner and test_panic_handler functions from our lib.rs. Since we want to test allocations, we enable the alloc crate through the extern crate alloc statement. For more information about the test boilerplate, check out the Testing post.

The implementation of the main function looks like this:

// in tests/heap_allocation.rs

fn main(boot_info: &'static BootInfo) -> ! {
    use blog_os::allocator;
    use blog_os::memory::{self, BootInfoFrameAllocator};
    use x86_64::VirtAddr;

    blog_os::init();
    let phys_mem_offset = VirtAddr::new(boot_info.physical_memory_offset);
    let mut mapper = unsafe { memory::init(phys_mem_offset) };
    let mut frame_allocator = unsafe {
        BootInfoFrameAllocator::init(&boot_info.memory_map)
    };
    allocator::init_heap(&mut mapper, &mut frame_allocator)
        .expect("heap initialization failed");

    test_main();
    loop {}
}

It is very similar to the kernel_main function in our main.rs, with the differences that we don’t invoke println, don’t include any example allocations, and call test_main unconditionally.

Now we’re ready to add a few test cases. First, we add a test that performs some simple allocations using Box and checks the allocated values to ensure that basic allocations work:

// in tests/heap_allocation.rs
use alloc::boxed::Box;

#[test_case]
fn simple_allocation() {
    let heap_value_1 = Box::new(41);
    let heap_value_2 = Box::new(13);
    assert_eq!(*heap_value_1, 41);
    assert_eq!(*heap_value_2, 13);
}

Most importantly, this test verifies that no allocation error occurs.

Next, we iteratively build a large vector, to test both large allocations and multiple allocations (due to reallocations):

// in tests/heap_allocation.rs

use alloc::vec::Vec;

#[test_case]
fn large_vec() {
    let n = 1000;
    let mut vec = Vec::new();
    for i in 0..n {
        vec.push(i);
    }
    assert_eq!(vec.iter().sum::<u64>(), (n - 1) * n / 2);
}

We verify the sum by comparing it with the formula for the n-th partial sum. This gives us some confidence that the allocated values are all correct.

As a third test, we create ten thousand allocations after each other:

// in tests/heap_allocation.rs

use blog_os::allocator::HEAP_SIZE;

#[test_case]
fn many_boxes() {
    for i in 0..HEAP_SIZE {
        let x = Box::new(i);
        assert_eq!(*x, i);
    }
}

This test ensures that the allocator reuses freed memory for subsequent allocations since it would run out of memory otherwise. This might seem like an obvious requirement for an allocator, but there are allocator designs that don’t do this. An example is the bump allocator design that will be explained in the next post.

Let’s run our new integration test:

> cargo test --test heap_allocation
[…]
Running 3 tests
simple_allocation... [ok]
large_vec... [ok]
many_boxes... [ok]

All three tests succeeded! You can also invoke cargo test (without the --test argument) to run all unit and integration tests.

🔗Summary

This post gave an introduction to dynamic memory and explained why and where it is needed. We saw how Rust’s borrow checker prevents common vulnerabilities and learned how Rust’s allocation API works.

After creating a minimal implementation of Rust’s allocator interface using a dummy allocator, we created a proper heap memory region for our kernel. For that, we defined a virtual address range for the heap and then mapped all pages of that range to physical frames using the Mapper and FrameAllocator from the previous post.

Finally, we added a dependency on the linked_list_allocator crate to add a proper allocator to our kernel. With this allocator, we were able to use Box, Vec, and other allocation and collection types from the alloc crate.

🔗What’s next?

While we already added heap allocation support in this post, we left most of the work to the linked_list_allocator crate. The next post will show in detail how an allocator can be implemented from scratch. It will present multiple possible allocator designs, show how to implement simple versions of them, and explain their advantages and drawbacks.

Как исправить ошибку “На компьютере недостаточно памяти”

В этой статье мы расскажем вам о 4 эффективных способах исправления ошибки Windows 10 “На компьютере недостаточно памяти”.

Содержание статьи:

Способ №1. Обслуживание системы

Чтобы исправить возникшую неполадку, воспользуйтесь приведенной ниже инструкцией:

1. Запустите Панель управления. Вы можете быстро найти данную утилиту просто начав писать ее название в меню Пуск.

2. Переключите вид отображения параметров на Крупные значки и найдите меню Устранение неполадок. Для более быстрого доступа к нему вы можете ввести название утилиты в диалоговом окне Поиск в панели управления.

3. В левом углу вы увидите список расширенных возможностей открытого окна. Выберите параметр Просмотр всех категорий.

4. Перед вами появится список всех доступных служб. Найдите в нем параметр Обслуживание системы и откройте его.

5. В появившемся окне диагностики неполадок нажмите Далее и устраните все возникшие на компьютере ошибки.

Способ №2. Увеличение файла подкачки

Иногда ответ на вопрос нехватки памяти может крыться в размере файла подкачки. Давайте разберем как его правильно настроить.

1. Откройте утилиту Выполнить при помощи клавиш Win + R.

2. В появившемся окне введите sysdm.cpl и нажмите ОК.

3. Откройте вкладку Дополнительно и в меню Быстродействие кликните по клавише Параметры.

4. В открывшемся окне откройте вкладку Дополнительно и в меню Виртуальная память кликните по клавише Изменить.

5. Снимите галочку с параметра Автоматически выбирать объем файла подкачки для всех дисков.

6. Укажите для системного диска (обычно это диск С:) Размер по выбору системы, нажмите Задать, ОК и перезапустите компьютер.

Обычно перезагрузка требуется только при уменьшении размера файла подкачки. Поэтому если вы его увеличивали, нет необходимости перезагружать компьютер.

Способ №3. Восстановление реестра

Иногда причиной возникшей неполадки может стать ошибка внутри реестра, которая может повлечь за собой повреждение и других системных функций. Ниже мы рассмотрим способ исправления повреждений реестра.

1. Воспользуйтесь комбинацией клавиш Win + R, чтобы открыть утилиту Выполнить. В диалоговом окне введите cmd и нажмите ОК.

Альтернативным способом запуска cmd является поиск утилиты при помощи меню Пуск и ее запуск от имени администратора.

2. В открывшемся окне командной строки введите команду sfc /scannow. Она проведет полное сканирование вашей системы, процесс которого может отнять некоторое время.

3. Дождитесь завершения проверки системы и перезапустите компьютер. Таким образом все поврежденные файлы будут удалены или исправлены.

Способ №4. Очистка временных файлов

Мы часто недооцениваем влияние временных файлов на загруженность нашей системы и очень зря, ведь они могут существенно повлиять на быстродействие наших компьютеров. Поэтому настоятельно рекомендуем вам проводить периодическую очистку таких документов.

1. Откройте меню Пуск.

2. В диалоговом окне введите команду Очистка диска и запустите найденную утилиту.

3. Выберите диск, который вы хотите очистить.

4. Кликните по клавише Очистить системные файлы и подтвердите корректность выбранного диска.

5. После того как вы ознакомитесь с данными о размере пространства, которое будет освобождено с помощью очистки, нажмите ОК и подтвердите запрос об удалении.

6. По завершению процесса перезапустите компьютер.

Способ №5. Закройте “тяжелые” программы

Нередко причиной нехватки памяти становятся грузные приложения, которые отнимают большое количество ресурсов компьютера, из-за чего он не может полноценно функционировать. В таком случае единственным доступным способом исправления неполадки является их отключение или же приобретение большего количества оперативной памяти.

1. Откройте приложение Диспетчер задач при помощи комбинации клавиш Ctrl + Alt + Del. Альтернативным и не менее удобным способом его запуска является щелчок правой кнопкой мыши по Панели задач и выбор Диспетчера из списка доступных вариантов.

2. Во вкладке Процессы отсортируйте приложения по графе Память. Это действие поможет расположить в топе списка самые “тяжелые” приложения, отнимающие большое количество ОЗУ. Завершите их процессы.

Похожие статьи про восстановление данных:

Как автоматически освободить место на жестком диске?

Иногда каждому из нас хочется каким-нибудь образом автоматизировать ту или иную сферу жизни. Сегодня.

20 способов ускорить Windows 10

Что такое SSD и как он работает

SSD (Solid State Drive) — давно не новый товар на рынке комплектующих для ПК, но его популярно.

Источник

Memory allocation for * bytes failed: причины и решения.

Прогресс и маркетинг дарят компьютерному пользователю стабильность в ценах на компьютерные составляющие и всё более оптимальную в подходе к этим составляющим операционную систему. Однако некоторых пользователей даже сегодня продолжает настигать «ошибка 2000-х» в виде аварийно захлопнувшегося приложения с сообщением Windows Memory allocation for * bytes failed. Так почему на фоне нередко переизбытка установленной RAM и запредельного по размерам pagefile.sys эта ошибка всё ещё досаждает некоторым из нас?

Проблема пришла к нам из тех времён, когда пользователи стали активно переходить с Windows XP на более современную Windows Vista и 7, пытаясь при этом сохранить прежнюю конфигурацию компьютера. Ошибка Memory allocation for * bytes failed — ни что иное как эхо ещё более коварной ошибки Unable to allocate memory, которая мучила владельцев «отстающих» сборок. Массовый переход производителей на 64-х битные версии процессоров, многоканальные проходы RAM решили проблему практически полностью. Однако…

СПРАВКА

К сожалению, вследствие ограниченного перевода локализаций Windows, пользователь не всегда способен правильно оценивать обстановку. А на неё Windows нередко прямо и указывает. В нашем случае ошибка Memory allocation for * bytes failed говорит о том, что оперативной памяти в указанном размере было отказано в выделении для этого приложения. Это значит, что отвечающая за перераспределение памяти процедура Управления памятью (Memory Management) просто не справляется с обязанностями. Учитывая границы зависимости MM, которые включают и аппаратные компоненты компьютера (RAM, чипсет, тип хранилища — SSD) и уровень приложений (объекты и структуры данных), можно предположить, что корни проблемы именно у вас никогда уже не решатся переустановкой Windows.

Memory allocation for * bytes failed: аппаратные ограничения

Ниже следуют наиболее вероятные причины ошибки. Они налагаются со стороны именно физического уровня аппаратного обеспечения:

Чуть подробнее…

Доступная память — самое простое объяснение. Если объём требуемой памяти превышает объёмы установленной, запросу со стороны программы системой будет отказано. Конечно, Windows и другие ОС сами себе создали уловку: они считают, что общая память складывается из нескольких факторов:

Этими показателями и объясняются очень многие «НО», из-за которых Windows не «отстёгивает» память, которую программа просит.

Memory allocation for * bytes failed: решения

Memory allocation for * bytes failed: ограничения со стороны системы

Тот случай, когда памяти много, а толку мало. Размер адресного пространства для конкретного процесса априори небольшой. Так память распределяется виртуальным Менеджером памяти, о котором мы уже упомянули: создаётся цепочка адресов памяти, которая связана с конкретным адресным пространством. А у адресного пространства всегда ограниченные границы значений. Так, для 32-х битных систем — это всегда лишь 4 Гб. Но это, вопреки обычному мнению, ещё и не весь предел накладываемым ограничениям. Системные адреса в процессе сеанса наносятся на адресное пространство, тем самым ещё более занижая свободное место. Так что порой, вопреки заявленным минимальным требованиям к «железу», операционная система Windows 7 (даже установленная «начисто»), например, оставит процессам не более 2—2,5 Гб оперативной памяти из 4-х Гб.

Memory allocation for * bytes failed: решения

И думать нечего: переходим на 64 бита. На всех платформах. А 32-х битные сборки пора перевозить в гараж. Тем более, у 64-х битных систем огромные преимущества в вопросах безопасности.

Memory allocation for * bytes failed: фрагментация памяти?

Отсюда начинается очень скользкая тема. Некогда популярные ремонтные утилиты нередко предлагали пользователям в числе прочего и такую функцию как дефрагментация оперативной памяти. Скользкая потому, что моё личное мнение таково: часто шкура выделки не стоит. При нормально работающей системе такие программы если не мешают, то просто бесполезны. На старых системах — да. С объёмом RAM 1,5 — 2 Гб — безусловно. Но сейчас даже смартфоны мощнее. И с такими характеристиками комфортно можно работать разве что в Windows Millenium. В том виде, как эта проблема существовала, она современных пользователей (с, прежде всего, достаточным объёмом памяти) уже не касается (кому интересно — подробности в ссылке): она целиком и полностью ложится на плечи разработчиков. И даже принудительная фрагментация оперативной памяти самой Windows во время загрузки программы-тяжеловеса не должна вызывать ошибки Memory allocation for * bytes failed. Однако… Проверьте, не использует ли ваша «проблемная» программа библиотеку Microsoft Foundation Classes (MFC).

Memory allocation for * bytes failed: решения

Источник

Error allocating memory как исправить windows 10 x64

Что такое ошибка «Недостаточно памяти» при копировании файлов? Как вы знаете, и жесткий диск, и оперативная память играют важную роль в выполнении любой операции на компьютере, поскольку для выполнения каждого процесса или задачи, выполняемой в системе, требуется некоторое хранилище ОЗУ, а также хранилище жесткого диска. Однако бывают случаи, когда вы можете получить следующие сообщения об ошибках при попытке скопировать файлы из одного места в другое:

«Недостаточно памяти или системных ресурсов, закройте некоторые окна или программы и попробуйте снова».

Эти ошибки вызваны ограничением кучи рабочего стола, когда памяти больше не хватает для завершения операции при копировании файлов. Если вы столкнетесь с какой-либо из этих ошибок, в этом посте вам будут предложены некоторые возможные исправления, которые могут увеличить его лимит, и, надеюсь, исправят эту ошибку на вашем компьютере с Windows 10.

Вы можете попробовать закрыть все открытые окна и программы, а затем снова попытаться скопировать файл и посмотреть, поможет ли это. Если нет, то переходите к приведенным ниже инструкциям. Но прежде чем вы это сделаете, убедитесь, что вы сначала создали точку восстановления системы. Таким образом, вы можете отменить внесенные вами изменения в любое время, если есть какие-то нежелательные изменения, которые вы хотите отменить. После создания точки восстановления системы выполните действия, указанные ниже.

Шаг 1: Нажмите клавиши Win + R, чтобы открыть служебную программу «Выполнить», введите в поле «Regedit» и нажмите «Ввод», чтобы открыть редактор реестра.

Шаг 2: Затем перейдите к этому разделу реестра: ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerSubSystems

Шаг 3: Теперь дважды щелкните DWORD с именем Windows, чтобы изменить его.

Шаг 4: Измените значения SharedSection в поле Value Data. Он должен быть в формате «SharedSection = aaaa, bbbb, cccc». Обратите внимание, что вам нужно изменить значение «bbbb» и «cccc». Поэтому, если вы используете операционную систему x86, установите значение bbbb на 12288 а затем установите значение для cccc равным 1024, С другой стороны, если вы используете операционную систему x64, установите для bbbb значение 20480 и значение cccc для 1024.

Шаг 5: Закройте редактор реестра и перезагрузите компьютер, чтобы изменения вступили в силу.

С другой стороны, есть еще один инструмент, который может помочь в устранении ошибки Out of Memory. Этот инструмент, называемый в Windows средством диагностики памяти, может помочь устранить ошибку нехватки памяти, проверяя и автоматически исправляя любые проблемы, связанные с памятью. Чтобы запустить его, выполните следующие действия:

Примечание: После того, как вы выберете предпочтительный вариант, ваш компьютер перезагрузится и проверит наличие проблем с памятью. Если он обнаружит какие-либо проблемы, он автоматически их исправит.

Поздравляем, вы только что самостоятельно исправили ошибку «Недостаточно памяти» при копировании файлов в Windows 10. Если вы хотите читать более полезный статьи и советы о посещении различного программного и аппаратного обеспечения errortools.com в день.

Вот как исправить ошибку «Недостаточно памяти» при копировании файлов в Windows 10 на компьютер. С другой стороны, если ваш компьютер испытывает проблемы, связанные с системой, которые необходимо исправить, существует решение в один клик, известное как Ресторо вы можете проверить, чтобы решить их.

Выполните полное сканирование системы, используя Ресторо. Для этого следуйте приведенным ниже инструкциям.

Источник

Ошибки распределения памяти могут быть вызваны медленным ростом файла страницы

В этой статье предусмотрен обход ошибок, которые возникают при частом выделении памяти приложениями.

Применяется к: Windows 10 — все выпуски
Исходный номер КБ: 4055223

Симптомы

Приложения, которые часто выделяют память, могут испытывать случайные ошибки из памяти. Такие ошибки могут привести к другим ошибкам или неожиданному поведению в затронутых приложениях.

Причина

Сбои в распределении памяти могут возникать из-за задержки, связанные с ростом размера файла страницы для поддержки дополнительных требований к памяти в системе. Возможной причиной этих сбоев является настройка размера файла страницы в качестве «автоматического». Автоматический размер файла страницы начинается с небольшого файла страницы и автоматически растет по мере необходимости.

Система IO состоит из многих компонентов, включая фильтры файловой системы, файловые системы, фильтры громкости, фильтры хранения и т. д. Определенные компоненты в данной системе могут привести к вариативности в росте файлов страниц.

Обходной путь

Чтобы решить эту проблему, необходимо вручную настроить размер файла страницы. Для этого выполните следующие действия:

Статус

Корпорация Майкрософт подтвердила, что это проблема в Windows 10.

Дополнительная информация

При использовании компиляторов Microsoft Visual C++ (cl.exe) могут возникнуть такие ошибки сборки, как следующие:

Дополнительные сведения об ошибках компиляторов Visual C++ и о том, как их обойти, см. в материале Precompiled Header (PCH) issues and recommendations.

Источник

Memory allocation errors can be caused by slow page file growth

This article provides a workaround for errors that occur when applications frequently allocate memory.

Symptoms

Applications that frequently allocate memory may experience random «out-of-memory» errors. Such errors can result in other errors or unexpected behavior in affected applications.

Cause

Memory allocation failures can occur due to latencies that are associated with growing the size of a page file to support additional memory requirements in the system. A potential cause of these failures is when the page file size is configured as «automatic.» Automatic page-file size starts with a small page file and grows automatically as needed.

The IO system consists of many components, including file system filters, file systems, volume filters, storage filters, and so on. The specific components on a given system can cause variability in page file growth.

Workaround

To work around this issue, manually configure the size of the page file. To do this, follow these steps:

Status

Microsoft has confirmed that this is a problem in Windows 10.

More information

You might see intermittent build errors like the following if you encounter this problem when using the Microsoft Visual C++ compiler (cl.exe):

For more information about the Visual C++ compiler errors and how to work around them, see Precompiled Header (PCH) issues and recommendations.

Источник