Tôi có thể dựa vào NULL trở về malloc không?

Question

Tôi đọc rằng trên hệ thống Unix, malloc có thể trả về con trỏ không NULL ngay cả khi bộ nhớ không thực sự khả dụng và cố gắng sử dụng bộ nhớ sau này sẽ kích hoạt lỗi. Vì tôi không thể bắt lỗi như vậy bằng cách kiểm tra NULL, tôi tự hỏi làm thế nào hữu ích nó là để kiểm tra NULL ở tất cả?

Trên một lưu ý liên quan, Herb Sutter nói rằng việc xử lý lỗi bộ nhớ C++ là vô ích, bởi vì hệ thống sẽ đi vào sự phân trang dài trước khi một ngoại lệ thực sự xảy ra. Điều này cũng áp dụng cho malloc không?

Answer 1

Trích dẫn Linux manuals:

Theo mặc định, Linux sau một chiến lược phân bổ bộ nhớ lạc quan. Điều này có nghĩa là khi malloc() trả về không NULL thì không có đảm bảo rằng bộ nhớ thực sự khả dụng. Đây là một lỗi thực sự tồi tệ. Trong trường hợp hệ thống đã hết bộ nhớ, một hoặc nhiều quy trình sẽ bị giết bởi kẻ giết người OOM khét tiếng. Trong trường hợp Linux được sử dụng trong những trường hợp mà nó sẽ ít mong muốn đột nhiên mất một số ngẫu nhiên chọn quy trình, và hơn nữa phiên bản hạt nhân là đủ gần đây, người ta có thể tắt hành vi overcommitting này sử dụng một lệnh như:

# echo 2 > /proc/sys/vm/overcommit_memory 

Bạn nên kiểm tra trả lại NULL, đặc biệt là trên hệ thống 32 bit, vì không gian địa chỉ quy trình có thể cạn kiệt trước RAM: trên Linux 32 bit, quy trình người dùng có thể có dung lượng địa chỉ có thể sử dụng là 2G - 3G như trái ngược với hơn 4G của tổng số RAM. Trên các hệ thống 64 bit, có thể vô ích khi kiểm tra mã trả về malloc, nhưng có thể được coi là thực hành tốt, và nó làm cho chương trình của bạn dễ dàng hơn. Và, hãy nhớ, dereferencing con trỏ null giết chết quá trình của bạn chắc chắn; một số trao đổi có thể không làm tổn thương nhiều so với điều đó.

Nếu malloc xảy ra để trở NULL khi một cố gắng phân bổ chỉ một lượng nhỏ bộ nhớ, sau đó người ta phải thận trọng khi cố gắng để phục hồi từ tình trạng lỗi như bất kỳ tiếp theo malloc có thể thất bại quá, cho đến khi đủ bộ nhớ có sẵn.

Toán tử C++ mặc định new thường là trình bao bọc trên cùng một cơ chế phân bổ được sử dụng bởi malloc().

Answer 2

Trên Linux, bạn có thể thực sự không dựa vào malloc trở NULL nếu đủ bộ nhớ là không có sẵn do chiến lược overallocation của hạt nhân, nhưng bạn vẫn nên kiểm tra cho nó bởi vì trong một số trường hợp mallocsẽ trở NULL, ví dụ khi bạn yêu cầu nhiều bộ nhớ hơn là có sẵn trong tổng số máy. Linux malloc(3) manpage gọi tổng thể là "một lỗi thực sự xấu" và có lời khuyên về cách tắt nó đi.

Tôi chưa bao giờ nghe nói về hành vi này cũng xảy ra trong các biến thể Unix khác.

Đối với "co thắt phân trang", điều đó phụ thuộc vào thiết lập máy. Ví dụ: tôi có xu hướng không thiết lập phân vùng trao đổi trên cài đặt Linux cho máy tính xách tay, vì hành vi chính xác mà bạn sợ có thể làm hỏng đĩa cứng. Tôi vẫn muốn các chương trình C/C++ mà tôi chạy để kiểm tra các giá trị trả về malloc, cung cấp thông báo lỗi thích hợp và khi có thể làm sạch sau khi chúng.

Answer 3

Để xem này từ một điểm khác để xem:

"malloc có thể trả về một con trỏ không NULL ngay cả khi bộ nhớ là không thực sự sẵn" không có nghĩa là nó luôn luôn trả về không NULL. Có thể (và sẽ) là trường hợp NULL được trả về (như những người khác đã nói), vì vậy kiểm tra này là cần thiết tuy nhiên.

Answer 4

Kiểm tra sự trở lại của malloc không giúp bạn nhiều bởi chính nó để làm cho phân bổ của bạn an toàn hơn hoặc ít bị lỗi hơn. Nó thậm chí có thể là một cái bẫy nếu đây là thử nghiệm duy nhất mà bạn thực hiện.

Khi được gọi với đối số là 0, tiêu chuẩn cho phép malloc trả về một loại địa chỉ duy nhất, không phải là con trỏ rỗng và bạn không có quyền truy cập. Vì vậy, nếu bạn chỉ kiểm tra xem sự trở lại là 0 nhưng không kiểm tra các đối số cho malloc, calloc hoặc realloc bạn có thể gặp phải một sự xâm nhập sau này.

Tình trạng lỗi này (bộ nhớ cạn kiệt) khá hiếm trong môi trường "được lưu trữ". Thông thường bạn đang gặp rắc rối lâu trước khi bạn gặp rắc rối với loại lỗi này. (Nhưng nếu bạn đang viết thư viện thời gian chạy, là một hacker hạt nhân hoặc tên lửa xây dựng này là khác nhau, và có các thử nghiệm làm cho cảm giác hoàn hảo.)

Mọi người sau đó có xu hướng trang trí mã của họ với điều kiện lỗi phức tạp mà span dòng, làm perror và các nội dung tương tự, có thể ảnh hưởng đến khả năng đọc của mã.

Tôi nghĩ rằng điều này "kiểm tra sự trở lại của malloc" được đánh giá quá cao, đôi khi thậm chí còn bảo vệ khá một cách giáo điều. Những thứ khác quan trọng hơn nhiều:

• luôn khởi tạo biến luôn. đối với các biến con trỏ, điều này rất quan trọng, để chương trình gặp sự cố độc đáo trước khi mọi thứ trở nên quá tệ. thành viên con trỏ chưa được khởi tạo trong struct s là nguyên nhân quan trọng của các lỗi khó tìm.
• luôn kiểm tra đối số malloc và Co. nếu đây là biên dịch hằng số thời gian như sizof toto không có vấn đề gì, nhưng luôn đảm bảo phân bổ véc tơ của bạn xử lý đúng trường hợp 0.

Một điều dễ dàng để kiểm tra trả lại malloc là kết thúc bằng một cái gì đó như memset(malloc(n), 0, 1). Điều này chỉ viết một 0 trong byte đầu tiên và treo độc đáo nếu malloc gặp lỗi hoặc n là 0 để bắt đầu.