Bug 1159326

Summary: Pointer mangling breaks Ruby on ARM
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: arjun.is, codonell, fweimer, jakub, law, pfrankli, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-29 14:35:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1120856, 1157936    

Description Vít Ondruch 2014-10-31 14:29:33 UTC
Description of problem:
This was previously resolved (disabled) for F21 in bug #1035773 and as it seems, it was later enabled in F20 [1] and I really don't understand why :/


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


How reproducible:


Steps to Reproduce:
1. fedpkg clone ruby
2. git checkout f20
3. fedpkg scratch-build --arches armv7hf

Actual results:
Ruby does not build.


Expected results:
Ruby builds.


Additional info:
I would appreciate if you can revert this commit [1], since it was known it breaks Ruby yet you backported it into stable version.


[1] http://pkgs.fedoraproject.org/cgit/glibc.git/commit/?h=f20&id=f4ab03df66ceb8f838af40e8f3afadc641b2155a

Comment 1 Vít Ondruch 2014-10-31 14:32:34 UTC
Note that the backport was requested in bug #1019452

Comment 2 Vít Ondruch 2014-12-08 09:22:20 UTC
Carlos, could you please do something about this?

Comment 3 Jakub Jelinek 2014-12-08 09:27:40 UTC
Ugh, supposedly it is Ruby that should be fixed, what it does is definitely not portable, and pointer mangling is as a security feature highly desirable.
Why doesn't Ruby need it on say x86_64 where the pointers are mangled too?

Comment 4 Vít Ondruch 2014-12-08 09:55:45 UTC
This is just about frame pointer [1]. Frame pointer encryption is disabled on F21+ while it got enabled on F20 and older later after the discussion. And yes, there is Ruby upstream ticket to fix this issue [2].



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1035773#c17
[2] https://bugs.ruby-lang.org/issues/9249

Comment 5 Vít Ondruch 2014-12-08 13:02:14 UTC
(In reply to Jakub Jelinek from comment #3)
> Ugh, supposedly it is Ruby that should be fixed.

Actually testing this once more, the Ruby 2.0.0 still fails:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8321623

While Ruby 2.2.0 gets past that point:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8321676

So upstream Ruby is probably fixed, but this is OT for F20.

Comment 6 Carlos O'Donell 2014-12-08 14:48:01 UTC
(In reply to Vít Ondruch from comment #2)
> Carlos, could you please do something about this?

Certainly, would you like us to backport the F21+ patch to F20 and disable the fp encryption in F20 also?

(In reply to Jakub Jelinek from comment #3)
> Ugh, supposedly it is Ruby that should be fixed, what it does is definitely
> not portable, and pointer mangling is as a security feature highly desirable.
> Why doesn't Ruby need it on say x86_64 where the pointers are mangled too?

There is likely a combination of architectural dependencies that make it require the fp on ARM to find the gc root. In order to fix this though someone would have to do the grunt work to figure it out. In the meantime upstream did not want to leave ruby broken and reverted the fp mangling.

Comment 7 Vít Ondruch 2014-12-08 14:50:35 UTC
(In reply to Carlos O'Donell from comment #6)
> (In reply to Vít Ondruch from comment #2)
> > Carlos, could you please do something about this?
> 
> Certainly, would you like us to backport the F21+ patch to F20 and disable
> the fp encryption in F20 also?

That would be sweet. Thank you!

Comment 8 Carlos O'Donell 2014-12-08 15:03:40 UTC
(In reply to Vít Ondruch from comment #7)
> (In reply to Carlos O'Donell from comment #6)
> > (In reply to Vít Ondruch from comment #2)
> > > Carlos, could you please do something about this?
> > 
> > Certainly, would you like us to backport the F21+ patch to F20 and disable
> > the fp encryption in F20 also?
> 
> That would be sweet. Thank you!

OK, we'll try to get to this when we do another f20 build, but that might take a while.

Comment 9 Vít Ondruch 2015-04-10 17:04:45 UTC
This is still an issue:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9457545

Comment 10 Fedora End Of Life 2015-05-29 13:11:54 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Carlos O'Donell 2015-05-29 14:35:32 UTC
We aren't going to get to this before June 23rd EOL. Closing as CLOSED/UPSTREAM.