Bug 169311

Summary: unresolved Symbol problems
Product: [Fedora] Fedora Reporter: Andreas Bierfert <andreas.bierfert>
Component: xorg-x11Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-27 07:31:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
stderr output of startx none

Description Andreas Bierfert 2005-09-26 21:15:21 UTC 
Description of problem:
Symbol __stack_chk_fail from module ...(see attached file) is unresolved!

Version-Release number of selected component (if applicable):
[11:19 PM][awjb@arcturus ~]$ rpm -q xorg-x11
xorg-x11-6.8.2-52

How reproducible:
always

Steps to Reproduce:
1. startx
Comment 1 Andreas Bierfert 2005-09-26 21:15:22 UTC 
Created attachment 119278 [details]
stderr output of startx
Comment 2 Mike A. Harris 2005-09-26 23:30:15 UTC 
This is caused by gcc's stack-protector.  It appears there is no "simple"
solution to work around this problem and keep stack-protector support
in the monolithic builds without more effort than it's worth to spend.

As such, I'm disabling stack-protector for monolithic builds.  Once modular
X hits the tree, everything should build ok with stack protector presumeably
except the X server, unless the problem has been resolved upstream by then.

We'll keep it disabled in the X server at least until we have a proper
solution that is also acceptable to upstream X.Org, as we definitely want
to avoid a Red Hat specific solution that causes inter-distribution binary
incompatibility of X server modules, as that would cause hardware vendors
to build modules for each distribution individually, which would be 'bad'
IMHO.
Comment 3 Mike A. Harris 2005-09-27 00:30:19 UTC 
Are you using FC4 with random bits and pieces of Fedora devel?  Curious
because another person using devel says they don't see this error.

I'm thinking the problem might only occur on mixed systems, although
it is a bigger problem than just the failure to solve.  Ultimately we
do want stack-protector to be used.  ;)
Comment 4 Andreas Bierfert 2005-09-27 07:21:53 UTC 
Actually its a devel with devel and fc4 repos enabled so if an fc4 version is >
fc5 there probably is some fc4 stuff in there... actually I probably should
track these packages down sometime ^^

Hope that helps. If you want an rpm -qa let me know...
Comment 5 Mike A. Harris 2005-09-27 07:31:03 UTC 
Should be fixed in 6.8.2-54, by disabling stack-protector completely.

When we put Xorg modular in rawhide, stack-protector will be automatically
re-enabled for everything except the Xorg X server, unless we come up with
a safe/sane way of doing so by then, as it'd be nice to have the additional
protection.  It'd cut down the seriousness of X server buffer overflows for
certain.

Thanks again for the report.