Bug 49815 - Segmentation violations in pthread_create
Summary: Segmentation violations in pthread_create
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.1
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-24 11:13 UTC by Wolfgang Stuehlmeyer
Modified: 2016-11-24 15:27 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2002-12-15 17:11:55 UTC


Attachments (Terms of Use)
DCOM for Linux - 6.1.1 Prerelease (6.17 MB, application/octet-stream)
2001-07-24 11:23 UTC, Wolfgang Stuehlmeyer
no flags Details

Description Wolfgang Stuehlmeyer 2001-07-24 11:13:41 UTC
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 11:23:43 UTC
Created attachment 24727 [details]
DCOM for Linux - 6.1.1 Prerelease

Comment 2 Jakub Jelinek 2001-07-25 11:04:01 UTC
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.