Description of problem: Statically building and running an executable that makes use of gethostbyname_r() and C++ exceptions on AS 3.0 is causing the process to segfault when the first exception is thrown. The executable and gethostbyname_r() appear to operating correctly in the process and all is well until we throw an exception. A stack trace indicates that the segfault occurs down in __cxa_throw () -- it never reaches the catch block. Removing the call to gethostbyname_r() causes the program to operate normally. See attachment for a short code example that produces this issue. This does not appear to be a dupe of bugs #89698 or #111298 (we do get the warning noted in this bug on build as expected) as we are building and running the executable on the same system, so the version of glibc/NSS/etc is the same as the version the executable was built with. If this is a linking issue, (dl_open() pulling in the wrong NSS/etc library at run time), why is it occuring on AS 3.0 if we built and linked the binary there? Switching the order of the try/catch block with gethostbyname_r() does not affect the results, ie gethostbyname_r doesn't have to execute or even be in the same scope as the throw. Building the executable with dynamic linking (g++ main.cc -o main) does not produce this problem, but we would like to provide (and many request) the option for our users to build statically. In addition, an executable statically built on Red Hat 9.0 does not produce this problem when run locally or when copied over and run on an AS 3.0 box. Version-Release number of selected component (if applicable): glibc-2.3.2-95.3 How reproducible: Always Steps to Reproduce: 1. g++ main.cc -o main -static (code in attachment) 2. main Actual results: Segfault with a core file indicating the segmentation fault occured inside throw(10). Expected results: Should have printed "Offical name = ...", "caught exception" and returned normally. Additional info:
Created attachment 98664 [details] Example code that causes a segfault when statically linking Statically linking and running on AS 3.0 causes this example to segfault when throw(10) is executed. "g++ main.cc -o main -static" was used.
Works for me: $ rpm -q glibc gcc binutils libstdc++ libstdc++-devel; g++ -g -o main{,.cpp} -static; ./main; echo $? glibc-2.3.2-95.17 gcc-3.2.3-31 binutils-2.14.90.0.4-34 libstdc++-3.2.3-31 libstdc++-devel-3.2.3-31 /tmp/cc2ZYlLR.o(.text+0x87): In function `main': /tmp/main.cpp:12: Using 'gethostbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Official name = tweety.devel.redhat.com caught exception 0 This is up2date U2 beta. Can you retry with U2 beta packages mentioned above?
Thanks for the quick reply! Working on obtaining this U2 beta package through our sysadmins -- might take a little time. I will also try to obtain Update 1 to see if that resolves it. The equivalent package query for our system (should be an unmodified install of AS 3): $ rpm -q glibc gcc binutils libstdc++ libstdc++-devel glibc-2.3.2-95.3 gcc-3.2.3-20 binutils-2.14.90.0.4-26 libstdc++-3.2.3-20 libstdc++-devel-3.2.3-20 Also, for what its worth, the systems are using the SMP enabled (with HT) kernel: 2.4.21-4.ELsmp
It seems we are currently unable to obtain these patches, and so are unable to confirm they resolve this issue. Our build process has been modified to now dynamically link to glibc, which appears to provide a satisfactory work-around at this time. I will leave this issue as NEEDINFO in case any further insight may be available.
Well, IMHO dynamically linking against glibc (and libpthread if needed) is not a workaround, but the most portable solution. Anyway, glibc-2.3.2-95.20 is available from ftp://people.redhat.com/jakub/glibc/errata/2.3.2-95.20/
No reply in 4 months. The errata is long out of the door. Reopen if you still see problems.