Re: [Pan-users] Weird bug with gcc-5.2's libstdc++

[Holger Hoffstätte]

On Wed, 12 Aug 2015 18:03:57 -0600, Zan Lynx wrote:

> On 08/12/2015 04:01 PM, Holger Hoffstätte wrote:
>> 
>> It gets weirder..
>> 
>> On Wed, 12 Aug 2015 21:43:08 +0000, Holger Hoffstätte wrote:
>> 
>>> On startup it can somehow no longer properly locate the ~/.pan2
>>> directory and always decides to create an empty newsrc-1 in my ~.
>> 
>> Actually it creates the newsrc-1 in the $CWD. Apparently the newly
>> built binary (using it right now) works fine when I start it in the
>> ~/.pan2 directory, where it can find the old newsrc and all settings.
>> Why the old version works without any $CWD (from an xfce launcher)
>> remains a mystery for now.
>> 
>> Suggestions welcome..
> 
> From a quick peek at the source code I don't see how it could be a
> problem with libstdc++. Instead I'd look for problems with glib.
> Specifically g_get_home_dir() and g_build_filename().

Interesting! Thanks for looking into this. I hadn't looked at the source 
yet. My first suspicion was a C++ dependency that needed rebuilding as 
well (gtkmm or the like), but pan has none and in that case I'd expect 
real breakage due to the std::string ABI changes anyway.

> Maybe your pan linked to the wrong version of glib somehow?

Nope, only one installed and if there was something wrong with that I'd 
have noticed already.

> Or it could be a faulty assumption that the char* returned remains
> valid. Most places in the code assign to a std::string which makes a
> copy and is great. Other places assign to a char* and I am not sure that
> the pointed-to value remains valid.
> 
> I checked and the glib docs say g_getenv()'s value remains valid only
> until the next call to a list of functions.
> 
> A change in how GCC compiles could be responsible for causing a
> temporary pointer to get overwritten which didn't happen with an older
> compiler.

That doesn't sound impossible (though horrible), but since I got the same 
effect after rebuilding with clang I suspected the stdlib first.

The fact that the old binary worked fine certainly points to a (common) 
change in compile-time behaviour and maybe std::string lifetime handling. 
Seems like the change in _GLIBCXX_USE_CXX11_ABI deserves a closer look.

> Or maybe you did something like export PAN_HOME without setting it.
> Because I see in the code that PAN_HOME overrides everything else, and
> it doesn't seem to check it for being blank.

Checked that too - PAN_HOME isn't ever set.

For now I simply set the CWD to ~/.pan2 in the launcher and things work 
fine, just as before. Maybe I'll strace/debug further on the weekend.

Thanks again!

Holger