Có một nhu cầu để kiểm tra NULL sau khi phân bổ bộ nhớ, khi hạt nhân sử dụng bộ nhớ overcommit

Question

Đó là thực tế chung để kiểm tra NULL (cho dù bộ nhớ được phân bổ thành công) sau một malloc(), một số điều như

void *ptr = malloc(10);  
if (ptr != NULL) { 
    // do some thing usefull 
} else { 
// no memory. safely return/throw ... 
} 

với overcommit bộ nhớ được kích hoạt trong hạt nhân, là có một cơ hội nhận được NULL? Tôi có nên thực hiện theo các thực hành kiểm tra tôn giáo NULL cho mỗi phân bổ? Liệu malloc trả về NULL có khơi gợi cơ chế overcommit tăng cường (tôi đoán giá trị 1)?

Như một vấn đề của thực tế hạt nhân Android sử dụng overcommit bộ nhớ (không chắc chắn về giá trị, rất thích biết nó (overcommit giá trị) và ý nghĩa của nó). Một số mã nguồn khung (C/C++) trong Android (có thể là bên thứ 3) không kiểm tra NULL cũng như không nhận được bad_alloc sau khi phân bổ. Tui bỏ lỡ điều gì vậy?

Có một số chủ đề trong SO liên quan đến bộ nhớ quá mức, nhưng không có chủ đề nào trong số đó giải quyết được sự nhầm lẫn của tôi.

CHỈNH SỬA: Nếu quá mức vượt quá đang được sử dụng NULL sẽ không được trả về (giả định 1). Khi không có bộ nhớ vật lý có sẵn và trên cố gắng truy cập vào bộ nhớ được cấp phát (ghi vào bộ nhớ được phân bổ), OOM sẽ giết một số tiến trình và cấp phát bộ nhớ cho ứng dụng cho đến khi nó bị giết lần lượt (giả định 2). Trong cả hai trường hợp tôi không thấy bất kỳ nhu cầu cho cheking NULL (bộ nhớ nhận được phân bổ hoặc quá trình nhận được giết chết). Tôi có đúng trong các giả định của tôi không?
Tính di động không phải là mối quan ngại cho câu hỏi này.

Answer 1

Có, bạn vẫn nên kiểm tra lỗi do malloc trả lại. Trong môi trường quá mức bộ nhớ, bạn sẽ không thể phát hiện và khôi phục từ thất bại do môi trường hết bộ nhớ vật lý cần thiết khi bạn ghi vào các phần của không gian địa chỉ đã được cấp phát cho chương trình của bạn bằng cuộc gọi trước tới malloc.

Tuy nhiên, đây không phải là vấn đề duy nhất khiến malloc thất bại trong môi trường truyền thống.Yêu cầu cho một khối bộ nhớ đặc biệt lớn khi không gian địa chỉ của chương trình của bạn bị phân mảnh có thể bị lỗi ngay cả khi có đủ bộ nhớ vật lý đủ khả năng để đáp ứng yêu cầu. Vì không có không gian địa chỉ miễn phí liền kề malloc phải không thành công. Loại lỗi này phải được báo hiệu bằng cách malloc trả lại NULL, cho dù môi trường có quá mức bộ nhớ hay không.

Answer 2

Bạn phải kiểm tra giá trị trả lại cho NULL mỗi lần. Bất kỳ chức năng thư viện nào đều có thể bị lỗi. Ngay cả fclose() làm (trên chia sẻ NFS bị ngắt kết nối, và lỗi từ fclose của tệp NFS có nghĩa là, dữ liệu đó không được lưu).

Phần lớn phần mềm được viết kém và không chứa tất cả các kiểm tra.

malloc không thể trả lại thứ gì khác ngoài NULL hoặc con trỏ. Tất cả hoặc không có gì. Bạn không thể nhận được 1 byte từ malloc nếu bạn yêu cầu 10.

Answer 3

Bạn nên kiểm tra NULL một cách tôn giáo trên tất cả các cuộc gọi hàm có thể trả về NULL, bất kể hạt nhân có bộ nhớ quá mức hay không.

này sau đoạn mã dưới đây cho thấy làm thế nào để kiểm tra xem các cuộc gọi đến malloc làm việc hay không ... hoạt động

 
void *ptr = malloc(10); 
if (ptr != NULL){ 
    /* Do something here with ptr */ 
}else{ 
    /* Do something here if it fails */ 
} 

File, hoạt động bộ nhớ để tên nhưng một vài sẽ trả về một NULL khi thất bại.

Hy vọng điều này sẽ giúp, Trân trọng, Tom.

Answer 4

Không, không cần phải kiểm tra kết quả của malloc.

Dài trước khi malloc bị lỗi, hệ điều hành đã gặp phải rất nhiều sự cố.