Bug 219638 - segfault in sample application
segfault in sample application
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.3
s390x Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-14 11:06 EST by Brock Organ
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-14 12:02:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
main() for program (284 bytes, text/plain)
2006-12-14 11:12 EST, Brock Organ
no flags Details
script to try different options (435 bytes, text/plain)
2006-12-14 11:12 EST, Brock Organ
no flags Details
shared library code (164 bytes, text/plain)
2006-12-14 11:14 EST, Brock Organ
no flags Details

  None (edit)
Description Brock Organ 2006-12-14 11:06:42 EST
* 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 (6.3.0.0-1.132.EL4rh)
> <...>
> 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
./libprobdemo.so
> #2  0x000002000001bf9c in global constructors keyed to myfunc () from
./libprobdemo.so
> #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 11:09:58 EST
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 11:12:05 EST
Created attachment 143649 [details]
main() for program
Comment 3 Brock Organ 2006-12-14 11:12:59 EST
Created attachment 143650 [details]
script to try different options
Comment 4 Brock Organ 2006-12-14 11:14:12 EST
Created attachment 143652 [details]
shared library code
Comment 5 Jakub Jelinek 2006-12-14 12:02:25 EST
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 14:20:36 EST
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 16:43:05 EST
customer is happy with this resolution/information ... many thanks, Jakub! :)

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