Memory area (e.g. 0xffffffffac11dec0)

MHermann

Hi all,

I have a question regarding memory areas.
Normally I get debug output with "normal" memory areas. E.g. 0x43c0ca8.
But sometimes I see e.g. 0xffffffffac11dec0.
This does not look normal for me.
Can someone tell me if this is an problem?

Kind regards,
MHermann

Christian Ehrlicher

@MHermann said in Memory area (e.g. 0xffffffffac11dec0):

Can someone tell me if this is an problem?

Why should this be a problem as long as your program does not crash. The OS decides where your variables and functions are mapped to.

Kent-Dorfman

@MHermann said in Memory area (e.g. 0xffffffffac11dec0):

Can someone tell me if this is an problem?

only if you are on an OS that doesn't use virtual memory addressing.

MHermann

Thanks for the answers.
I was wondering if this address is okay.
Because in debug mode I can see that a "normal" address is used and only in release mode this "special" address is used.

Chris Kawa

As Christian said at the end it's up to the OS what addresses you get, but there are various features that can influence it.

One such is ASLR which is a security feature that basically randomizes the base address of your process every time it runs, so that attackers can't make assumptions about it. Depending on your toolchain or linker settings it might be enabled in release builds but not in debug.

Another such feature (on windows at least) is the debug heap. It's a special type of heap used by default in debug builds that does stuff like zeroing allocations, tracking dead zones etc. It could get a different virtual address than the default heap in release mode.

There's a /LARGEADDRESSAWARE on msvc that allows addresses above 2GB etc. that could also be enbled in one build type and not the other.

There's more stuff like that, so I wouldn't say there's anything wrong with these addresses at first glance.