内存 (sbrk) 指针访问时 16 字节对齐移位

发布于 2024-08-06 01:51:12 字数 706 浏览 8 评论 0原文

我使用 sbrk 编写了一个相当基本的内存分配器。我请求一块内存,比如 65k,并根据需要将其划分为请求动态内存的变量。我通过将内存添加回 65k 块来释放内存。 65k 块源自联合 sizeof(16 字节)。然后我沿着偶数 16 字节边界对齐该块。但我的行为异常。

当我分配并开始填充我的数据结构时,访问内存看起来很好,接受在我的一个函数调用中,我将一个指针传递给全局结构中的成员变量,但指针参数的地址不会直接映射到该成员的地址。

例如,这个特定成员的真实地址恰好是:0x100313d50,但是当执行特定函数(没什么特别的)时,该成员的地址被表示为0x100313d70。在调试器内部,我可以查询真实地址,并且在显示此地址的函数内部时,它看起来是正确的。这也不是第一个被访问的成员,而是第三个,因此之前的两次内存访问都很好,但在第三次访问期间,我看到了这种不寻常的转变。

我是否有可能通过未对齐的块访问该内存?这是可能的,但我希望抛出 SIGBUS 异常(SPARC 芯片)。我正在使用 -memalign=16s 进行编译,因此它应该是 SIGBUS 而不是捕获和修复未对齐。

我的所有结构都填充了 16 字节的倍数:sizeof(struct)%16 = 0。有人有过这种类型的行为经验吗?一般来说,什么类型的东西/东西/等等。可能会导致指针错误地表示内存地址?

干杯, 特雷西。

Solaris 10、SunStudio-12、现代 SPARC 处理器上的 C 语言(如果这有帮助的话)。

I wrote a reasonably basic memory allocator using sbrk. I ask for a chunk of memory, say 65k and carve it up as needed for variables requesting dynamic memory. I free the memory by adding it back to the 65k block. The 65k block is derived from a union sizeof(16-bytes). Then I align the block along an even 16-byte boundary. But I'm getting unusual behavior.

Accessing the memory appears fine as I allocate and begin to populate my data structures accept that on one of my function calls, I pass a pointer to a member variable in a global structure but the address of the pointer argument doesn't map directly to the address of that member.

For example, the real address of this particular member happens to be: 0x100313d50 but when executing a particular function (nothing special) the address of the member is being represented as 0x100313d70. Inside the debugger I can query the real address and it appears correct when inside the function where this manifests. This isn't the first member being accessed either, it's the third so two prior memory accesses are fine, but during the third access I'm seeing this unusual shifting.

Is it possible that I'm accessing this memory via a misaligned block? It's possible but I'd expect the get a SIGBUS exception thrown (SPARC chip). I'm compiling using -memalign=16s so it ought to SIGBUS instead of trapping and fixing the misalignment.

All of my structures are padded on a multiple of 16-bytes: sizeof(structure)%16 = 0. Has anyone had experience with this type of behavior? Generally speaking, what type of things/stuff/etc. might cause a pointer to misrepresent a memory address?

Cheers,
Tracy.

Solaris 10, SunStudio-12, C language on modern SPARC processor (in case this helps).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

不疑不惑不回忆 2024-08-13 01:51:12

我想如果其他人也有类似的问题,我应该回答我自己的问题。

内存地址移动的原因是因为先前对实用程序函数的调用意外地覆盖了全局结构的元地址,从而重写了该块的元地址,因此即使实际数据仍然驻留,对该块的查找也发生了移动在原始块中。

简而言之,我写的超出了我的缓冲区。由于我从尾部分发内存,覆盖会消除我的全局结构(或其他)急需的元地址。现在我知道未定义的行为是什么样的了。

I figure I should answer my own question in the event someone else out there has a similar problem.

The reason why the memory address was shifting is because a prior call to a utility function accidentally overwrote the meta-address of the global structure thusly rewriting the meta-address of that block so lookups on that block were shifted even though the actual data still resided in the original block.

In simple words, I wrote past my buffer. Since I hand out memory from the tail, overwriting would blow away my much needed meta-address for my global structure (or whatever). Now I know what undefined behavior looks like.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文