possible bug with 0.7.1 RC1 and memory (variable) corruption #1920

I tried the last official 0.7.1 RC1 on Windows 7 and was browsing through debug.log. One line was drawing my attention:

<pre> 10/11/12 20:10:57 Default data directory C:\Users\Diapolo\AppData\Roaming\Bitcoin 10/11/12 20:10:57 Used data directory 10/11/12 20:10:57 </pre>

Seems like pszDataDir (https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L483) does NOT contain what it should print there. I currently have no time to investigate, but to me this seems to be a problem with https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L443.

(RC1 does not include #1901, which could be a cause? - As the build is from 2012-10-09 it is not :-D.) Perhaps the call to GetDataDir() with .string().c_str() attached causes a problem, because it's the first one (caching issue), I dunno.

This does not happen with my local build, which has #1901 included!

@diapolo you're right. This is a classical use-after-free:

const char* pszDataDir = GetDataDir().string().c_str();

• string() creates a temporary string
• c_str takes a pointer (which is a non-owning reference) to the buffer of that temporary string
• the temporary string is freed after leaving this statement
• we have a pointer pointing to unallocated memory, which gives us a fun surprise (the stringified date, even!)

Subtle bugs like this are why I always (less subtly) encourage people to use proper string types and not char*. This one must have slipped by :(

Going to take a stab at fixing it.

#1921

@laanwj You can hit me, but I had a bad feeling when Gavin started using this const char * with the BDB excpetion hardening patch and was thinking about asking him to use a std::string, but as I nit-picked too often over the past weeks I keept quiet ... seems that was wrong.

Thanks for fixing this :)!

Closing, as a patch was merged!