Bug 163083 - Statically linked C++ program using pthreads will segfault
Summary: Statically linked C++ program using pthreads will segfault
Status: CLOSED DUPLICATE of bug 115157
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
(Show other bugs)
Version: 4
Hardware: i386 Linux
medium
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-12 19:31 UTC by Jason Beardsley
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-13 11:54:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jason Beardsley 2005-07-12 19:31:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511

Description of problem:
A C++ program that uses pthreads and the STL (or string) will segfault.  If no STL header is included, the program does not crash.

This is apparently due to certain pthreads functions not being included in the output executable.  This bug may duplicate #115157, and I apologize if so, but hopefully the included test case will be useful.


Version-Release number of selected component (if applicable):
gcc-4.0.0-8

How reproducible:
Always

Steps to Reproduce:
foo.cpp:

#include <pthread.h>
#include <string> // or <list> or <vector> etc
int main()
{
  pthread_mutex_t lock;
  pthread_mutex_init(&lock, NULL);
  return 0;
}

1. Compile as follows: g++ -g -static foo.cpp -o foo -lpthread
2. Run it in gdb.
3. Note the address of pthread_mutex_init is 0.


Actual Results:  GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/jason/t/foo
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xad7000

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x08048232 in main () at foo.cpp:7


Expected Results:  No segfault

Additional info:

The suggestion in #115157 to forcibly link in all of libpthread.a is a valid workaround.

Linking dynamically also avoids the problem, however this is not possible in certain situations (e.g. creating a profiled executable requires static linking to be useful).

Comment 1 Jakub Jelinek 2005-07-13 11:54:08 UTC
Yes, this is a dup of #115157.

*** This bug has been marked as a duplicate of 115157 ***


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