<div dir="ltr">Greetings,<br clear="all"><div><br></div><div>I maintain the gcl package for Fedora. Upstream recently announced support for both ppc64 and ppc64le, so I attempted a build. However, the build is failing on an mprotect() call that looks, to me, like it ought to succeed. This is not happening on any other architecture, so it is either something in the ppc64-specific gcl code, or some quirk of Fedora ppc64 systems. Here is an example build, with lots of debug prints added by yours truly: <a href="http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2132156">http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2132156</a></div><div><br></div><div>In this case, it is the ppc64le build that failed, but it is the ppc64 build just as often. We're in a race to see which one can die first.</div><div><br></div><div>Here's why I think the mprotect() should have succeeded. Near the bottom of build.log, you'll see a line that reads:</div><div><br></div><div>mprotect failure: 0x1470000 65536 7: Permission denied<br></div><div><br></div><div>... meaning that we called mprotect(0x1470000, 65536, PROT_READ | PROT_WRITE | PROT_EXEC), it returned -1 to indicate failure, and errno == EACCES. Above that is the contents of /proc/<pid>/smaps immediately after the failing mprotect() call. If you dig through that, you can find the relevant memory region:</div><div><br></div><div><div><div>01210000-19b2f0000 rw-p 00000000 00:00 0 [heap]</div><div>Size: 6718336 kB</div><div>Rss: 5440 kB</div><div>Pss: 5440 kB</div><div>Shared_Clean: 0 kB</div><div>Shared_Dirty: 0 kB</div><div>Private_Clean: 0 kB</div><div>Private_Dirty: 5440 kB</div><div>Referenced: 5440 kB</div><div>Anonymous: 5440 kB</div><div>AnonHugePages: 0 kB</div><div>Swap: 0 kB</div><div>KernelPageSize: 64 kB</div><div>MMUPageSize: 64 kB</div><div>Locked: 0 kB</div><div>VmFlags: rd wr mr mw me ac </div></div></div><div><br></div><div>As we can see from VmFlags, this memory region has the may-read, may-write, and may-execute flags set, so there is no problem there. The koji builders have SELinux turned off (verified by running selinuxenabled at the top of %build; see the message "SELinux is off. Smooth sailing ahead."), so thjis is not an SELinux denial.</div><div><br></div><div>Can anybody think of any reason why that mprotect() call would have failed? Note that lots of similar mprotect() calls succeeded before this one failed.</div><div><br></div><div>Thanks for any suggestions you can give. Regards,</div>-- <br>Jerry James<br><a href="http://www.jamezone.org/" target="_blank">http://www.jamezone.org/</a><br>
</div>