Bug 118674

Summary: Static link to gethostbyname_r and using C++ exceptions causes segfault
Product: Red Hat Enterprise Linux 3 Reporter: Seth Cooper <cooper_seth>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 3.0CC: cooper_seth
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-26 05:59:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Example code that causes a segfault when statically linking none

Description Seth Cooper 2004-03-18 19:53:19 UTC 
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:
Comment 1 Seth Cooper 2004-03-18 20:09:28 UTC 
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.
Comment 2 Jakub Jelinek 2004-03-18 20:34:45 UTC 
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?
Comment 3 Seth Cooper 2004-03-19 11:32:04 UTC 
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
Comment 4 Seth Cooper 2004-04-07 02:11:42 UTC 
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.
Comment 5 Jakub Jelinek 2004-04-07 06:28:04 UTC 
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/
Comment 6 Ulrich Drepper 2004-08-26 05:59:22 UTC 
No reply in 4 months.  The errata is long out of the door.  Reopen if
you still see problems.