Bug 219638

Summary: segfault in sample application
Product: Red Hat Enterprise Linux 4 Reporter: Brock Organ <borgan>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3CC: fweimer, jamisonm
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-14 17:02:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
main() for program
script to try different options
shared library code none

Description Brock Organ 2006-12-14 16:06:42 UTC
* RHEL4 U3 s390x
* customer reported issue
* behavior verified and duplicated internally using RHEL4 U4 s390x

The customer reports receiving a segmentation fault when running the attached
sample program.  I have reproduced/verified the behavior interally as well:

> # g++ -shared -o libprobdemo.so probdemo-so.cc
> # g++ -o probdemo probdemo-main.cc -lprobdemo -Wl,-rpath,. -L.
> # ./probdemo
> Segmentation fault
> # 

Here is a gdb backtrace of the problem:

> # gdb ./probdemo
> GNU gdb Red Hat Linux (
> <...>
> This GDB was configured as "s390x-redhat-linux-gnu"...(no debugging symbols found)
> Using host libthread_db library "/lib64/tls/libthread_db.so.1".
> (gdb) run
> Starting program: /root/probdemo 
> (no debugging symbols found)
> <...>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000020080000a14 in ?? ()
> (gdb) bt
> #0  0x0000020080000a14 in ?? ()
> #1  0x000002000001bf2c in __static_initialization_and_destruction_0 () from
> #2  0x000002000001bf9c in global constructors keyed to myfunc () from
> #3  0x000002000001c02e in __do_global_ctors_aux () from ./libprobdemo.so
> #4  0x000002000001bb54 in _init () from ./libprobdemo.so
> #5  0x000002000000c668 in _dl_init_internal () from /lib64/ld64.so.1
> #6  0x0000020000000c7c in _dl_start_user () from /lib64/ld64.so.1
> (gdb)

Comment 1 Brock Organ 2006-12-14 16:09:58 UTC
Here is the customer's analysis of the problem:

> The problem occours when C++ iostreams are used in a shared object.  
> The shared object is being loaded well above the first 4GB of the 
> process's address space (around 0x0000020000010000) while the executable
> itself is being loaded in the first 4GB (around 0x0000000080000000).  
> The global constructors in the shared library are trying to call a C++ 
> library support function that was linked into the main executable 
> (_ZNSt8ios_base4InitC1Ev) using a "brasl" instruction which is resticted 
> to a 32-bit offset.  This causes the program to branch to unused memory
> (resulting in a SIGSEGV).
> Attached are two files to demonstrate the crash we are observing.  
> To compile and run:
>  g++ -shared -o libprobdemo.so probdemo-so.cc
>  g++ -o probdemo probdemo-main.cc -lprobdemo -Wl,-rpath,. -L.
>  ./probdemo

Comment 2 Brock Organ 2006-12-14 16:12:05 UTC
Created attachment 143649 [details]
main() for program

Comment 3 Brock Organ 2006-12-14 16:12:59 UTC
Created attachment 143650 [details]
script to try different options

Comment 4 Brock Organ 2006-12-14 16:14:12 UTC
Created attachment 143652 [details]
shared library code

Comment 5 Jakub Jelinek 2006-12-14 17:02:25 UTC
User error.  s390x doesn't support non-PIC shared libraries (similarly to most
other architectures) and even where it is somehow supported it is highly
desirable to avoid them.  Just compile objects which should be linked into the
shared library with -fpic or -fPIC.

Comment 6 Brock Organ 2006-12-14 19:20:36 UTC
verified Jakub's suggestion works in this case in our internal environment:

> # g++ -fpic -shared -o libprobdemo.so probdemo-so.cc
> # g++ -o probdemo probdemo-main.cc -lprobdemo -Wl,-rpath,. -L.
> # ./probdemo 
> main: about to call .so
> Hello from the .so
> main: back from .so
> # 

Comment 7 Brock Organ 2007-01-03 21:43:05 UTC
customer is happy with this resolution/information ... many thanks, Jakub! :)