Pan shows odd behaviour/crashes when rebuilt with gcc-5.2 (see $URL for discussion/triage), due to the change in libstdc++ std::string handling. Rebuilding pan with the old ABI behaviour fixes the problem reliably and in a nonintrusive, backwards-compatible way. Reproducible: Always Steps to Reproduce: 1. build pan with gcc-5.2.0 2. start it 3. witness random crashing or lack of configuration Actual Results: Random crashes on startup, odd behaviour due to environment variables and/or other temp. information being overwritten (timing-dependent). Expected Results: No crashes, pan should be able to find its ~/.pan2 config directory. This bug is clearly a problem in pan itself as the code seemed to work withthe old std::string behaviour, where CoW saved pointer contents from being eaten prematurely. Until this is fixed upstream simply reverting to the old ABI behaviour seems to be the simplest fix.
Created attachment 411056 [details, diff] Suggested fix to enforce the old std::string ABI
(In reply to Holger Hoffstätte from comment #1) No. We are not going to put bandaids on upstream's lack of experience with c++ by forcing a particular implementation of libstdc++ that happens to make pan not crash by lucky accident. This needs to be fixed properly.
Fixed in pan-0.139-r1 Patch submitted upstream at https://bugzilla.gnome.org/show_bug.cgi?id=754698 Please test! https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3e828ee766a6ebaa5c71ed1764f7998d59c24054 commit 3e828ee766a6ebaa5c71ed1764f7998d59c24054 Author: Alexandre Rostovtsev <tetromino@gentoo.org> Date: Mon Sep 7 13:29:52 2015 -0400 net-nntp/pan: fix newsrc-* files created in wrong place with g++-5 Gentoo-Bug: 559666 Reported-by: Holger Hoffstätte Upstream-Bug-url: https://bugzilla.gnome.org/show_bug.cgi?id=754698 Package-Manager: portage-2.2.20.1
Thanks for this proper fix; I hadn't looked at the code yet. After seeing your patch I agree that returning a reference to a static string is the right thing to do here. Upgraded to -r1 and it seems to be working fine so far.