On Mon, Mar 17, 2014 at 06:12:13PM +0100, Stefan Ring wrote: > At the company where I work, we have a large program using Boost > Python (1.54). We do our product builds for RHEL 5 and recently > started building using gcc 4.8 from RedHat devtoolset 2 for > performance. This works well, except for one system where it would > deterministically crash. I traced it to an old version of libgcc, and > specifically this patch, which RedHat applied to its 5.5 release in > 2009: > <http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/b5e52bbfb4bb11a6cbed452927fba979/files/118>. > I built libgcc myself with and without the patch, with the program > crashing reliably without the patch, and no crash with the patch > applied. Unfortunately, gdb does not show a meaningful stack trace, at > least not the old version from RHEL 5. > > When trying to find out a bit more about the patch, I was rather > surprised to see that (1) it is not applied to the mainline gcc code > and (2) it still applies cleanly. Since I don't have a good stack > trace, I cannot even try to build a suitable reproducer at the moment. > > Is there a good reason for not having it in mainline gcc? I suppose it > got lost or forgotten somehow, and that it would be good to have it > applied.
I don't remember it well, but from re-reading the gcc-patches threads around that time like: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html it seems that the actually committed fix for the bug that the gcc41-unwind-restore-state.patch was meant to fix was http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as http://gcc.gnu.org/r118068 The reason for not backporting that change was supposedly (my memory is fuzzy about it) to minimize the amount of structure layout changes in what is in the unwinder for buggy programs sometimes semi-public. While the GCC driver will attempt to link the unwinder preferrably only as libgcc_s.so.1 or into executables only to avoid many different copies of the unwinder, possibly from different GCC versions, if one overrides that and exports different versions of the unwinder from different shared libraries, there is always a risk that e.g. a subset of the unwinder symbols from older version of GCC unwinder comes earlier in search scope, and for the rest of symbols (e.g. those added in a newer version of GCC unwinder, though that happens only very rarely) they are exported from the newer GCC unwinder and then can't communicate together because some internal data structure changed. If you are talking about devtoolset, that compiler doesn't come with it's own libgcc_s.so.1, uses the system one, just its own libgcc_eh.a, so e.g. if you'd use the default -shared-libgcc (for g++), then it should make no difference at all, because you'd be using the same system unwinder all the time. Jakub
