Home/ Questions/Q 388441
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T15:46:12+00:00

I wrote a reasonably basic memory allocator using sbrk. I ask for a chunk

  • 0

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).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0