Bug 49815 - Segmentation violations in pthread_create
Segmentation violations in pthread_create
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-24 07:13 EDT by Wolfgang Stuehlmeyer
Modified: 2016-11-24 10:27 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 12:11:55 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)
DCOM for Linux - 6.1.1 Prerelease (6.17 MB, application/octet-stream)
2001-07-24 07:23 EDT, Wolfgang Stuehlmeyer
no flags Details

  None (edit)
Description Wolfgang Stuehlmeyer 2001-07-24 07:13:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

Description of problem:
Could not install and run ower DCOM for Linux.
Reason: Segmentation violation in pthread_create.
This is a Red Hat 7.1 problem only.
The same binaries are running under Red Hat 6.1, 6.2, 7.0,
7.0 including Update 7.1, and SuSE 6.3 to 7.2.



How reproducible:
Always

Steps to Reproduce:
1. Install  rpm -i dcom-license-v...
2. Install  rpm -i dcom-v...
	

Actual Results:  Program "dcomcnfg -init" hangs.

Reason: Segmentation violation in pthread_create.

Expected Results:  no hanging dcomcnfg.

Additional info:

Not reproducible with a small program.
You need ower DCOM for Linux rpm file to reproduce the problem.

Multiple of ower customers need a solution.
Comment 1 Wolfgang Stuehlmeyer 2001-07-24 07:23:43 EDT
Created attachment 24727 [details]
DCOM for Linux - 6.1.1 Prerelease
Comment 2 Jakub Jelinek 2001-07-25 07:04:01 EDT
Can you
export LD_ASSUME_KERNEL=2.2.5
and retry?
Unlike glibc in RHL 7.0, i686 libpthread in 7.1 by default uses %gs as thread
pointer (which means threads are not stuck with fixed 2M thread stacks),
they can use far smaller stacks (thus more threads can be created) or bigger
stacks, also not all threads have to use the same stack size.
But this is incompatible with applications which either clobber %gs register,
or call modify_ldt(2) themselves. If DCOM is such a case, then it should be
fixed (it is enough if it starts using segment descriptors from the last one
downwards, as glibc uses them from 0 up to max number of threads).

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