Bug 118674 - Static link to gethostbyname_r and using C++ exceptions causes segfault
Summary: Static link to gethostbyname_r and using C++ exceptions causes segfault
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-18 19:53 UTC by Seth Cooper
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-26 05:59:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Example code that causes a segfault when statically linking (415 bytes, text/plain)
2004-03-18 20:09 UTC, Seth Cooper
no flags Details

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):


How reproducible:


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 $?
/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
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

Also, for what its worth, the systems are using the SMP enabled (with
HT) kernel:

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.

Note You need to log in before you can comment on or make changes to this bug.