Địa chỉ 0000000C có phải là địa chỉ đặc biệt không?

Khi lập trình đôi khi mọi thứ bị phá vỡ. Bạn đã mắc lỗi và chương trình của bạn cố đọc từ một địa chỉ sai.

Một điều nổi bật với tôi rằng thường những ngoại lệ đó là:

Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C.

Bây giờ tôi thấy rất nhiều nhật ký lỗi và điều nổi bật với tôi là: 0000000C. Đây có phải là một địa chỉ "đặc biệt" không? Tôi thấy các vi phạm truy cập khác với các lần đọc xấu nhưng các địa chỉ có vẻ ngẫu nhiên, nhưng địa chỉ này tiếp tục quay lại trong các tình huống hoàn toàn khác nhau.

00000000là một địa chỉ đặc biệt (con trỏ null). 0000000Cchỉ là những gì bạn nhận được khi bạn thêm phần bù 12 vào con trỏ null, rất có thể là do ai đó đã cố gắng lấy zthành viên của cấu trúc như cấu trúc bên dưới thông qua một con trỏ thực sự là null.

struct Foo {
    int w, x, y; // or anything else that takes 12 bytes including padding
    // such as: uint64_t w; char x;
    // or: void *w; char padding[8];
    // all assuming an ordinary 32 bit x86 system
    int z;
}

Trong Windows nó là bất hợp pháp để dereference các toàn bộ trang đầu tiên và cuối cùng , nói cách khác là người đầu tiên hoặc cuối cùng 64 KiB của bộ nhớ quá trình (các dãy 0x00000000để 0x0000ffffvà 0xffff0000để 0xfffffffftrong một ứng dụng 32-bit).

Điều này là để bẫy hành vi không xác định của việc hủy bỏ một con trỏ hoặc chỉ mục null thành một mảng null. Và kích thước trang là 64 KiB, vì vậy Windows chỉ cần ngăn trang đầu tiên hoặc trang cuối cùng được gán một phạm vi hợp lệ.

Điều này sẽ không bảo vệ chống lại con trỏ chưa được khởi tạo có thể có bất kỳ giá trị nào (bao gồm cả địa chỉ hợp lệ).

Về lý do tại sao 0x0Ccó vẻ phổ biến hơn 0x08(thực sự là vậy? Tôi không biết; và trong các loại ứng dụng nào?), Điều này có thể phải làm với các con trỏ bảng phương thức ảo. Đây thực sự là một nhận xét nhiều hơn (đoán đại chúng hoang dã :), nhưng nó có phần lớn hơn, vì vậy hãy đến đây ... Nếu bạn có một lớp học với các phương thức ảo, các trường riêng của nó sẽ bị thay đổi 0x04. Ví dụ, một lớp kế thừa từ một lớp ảo khác có thể có bố cục bộ nhớ như thế này:

0x00 - VMT pointer for parent
0x04 - Field 1 in parent
0x08 - VMT pointer for child
0x0C - Field 1 in child

Đây có phải là một kịch bản phổ biến, hoặc thậm chí đóng? Tôi không chắc. Tuy nhiên, lưu ý rằng trong ứng dụng 64 bit, điều này thậm chí có thể chuyển sang 0x0Cgiá trị thú vị hơn :

0x00 - VMT parent
0x08 - Field 1 parent
0x0C - VMT child
0x14 - Field 2 child

Vì vậy, thực sự có rất nhiều trường hợp các ứng dụng có thể có sự chồng chéo đáng kể trong các con trỏ null. Nó có thể là trường đầu tiên trong lớp con hoặc con trỏ bảng phương thức ảo của nó - cần thiết bất cứ khi nào bạn gọi bất kỳ phương thức ảo nào trên một cá thể, vì vậy nếu bạn gọi một phương thức ảo trên một nullcon trỏ, bạn sẽ bị vi phạm quyền truy cập trên nó VMT bù. Sự phổ biến của giá trị cụ thể này sau đó có thể có liên quan đến một số API phổ biến cung cấp một lớp có kiểu kế thừa tương tự, hoặc nhiều khả năng là một giao diện cụ thể (hoàn toàn có thể đối với một số lớp ứng dụng, như trò chơi DirectX). Có thể theo dõi một số nguyên nhân phổ biến đơn giản như thế này, nhưng tôi có xu hướng loại bỏ các ứng dụng làm hội thảo vô hiệu hóa khá nhanh, vì vậy ...