 <p>All your mess is really goes from fact, that you don't know if cfg was allocated on heap or wasn't. Just calling malloc somewhere on startup means nothing -- libc calls malloc several times even for void program.</p> <p>Let me explain you how to determine where your data is.</p> <p>Lets start with your code, some modified:</p> <pre><code>#include "stdlib.h" class Config { public: Config(int spi) {_spi = &amp;spi;} virtual ~Config() {;} private: int *_spi; }; Config cfg(2); int main(void) { int *x = new int(2); return 0; } </code></pre> <p>Now lets compile it with <code>g++ -g -O0 statstorage.cpp -static</code></p> <p>You got a.out file. Now we must look where your data are actually are. First call gdb with command line like this:</p> <pre><code>echo -e "start\nstep\np/x &amp;cfg\np/x x\nquit" &gt; .gdbinit &amp;&amp; gdb a.out </code></pre> <p>You will got output like this:</p> <pre><code>$1 = 0x6add50 $2 = 0x6c5670 </code></pre> <p>Where 0x6add50 is address of your cfg, and 0x6c5670 is address of dynamically allocated x pointer.</p> <p>Now lets call readelf, like <code>readelf -S a.out</code></p> <p>And look where sections are. Output is (for my pc) 38 sections. All we need is Address field and Size field. I have:</p> <pre><code> Address Size [23] .bss ... 00000000006add00 ... 0000000000014d38 [24] __libc_freeres_pt ... 00000000006c2a38 ... 0000000000000030 </code></pre> <p>And __libc_freeres_pt is the last section with the biggest non-null address.</p> <p>We can see, that 0x6c5670 is outside loaded binary (in heap itself), and cfg is inside bss section.</p> <p>This yields, taht cfg <strong>was</strong> allocated statically.</p>