RPM Packages for Bumblebee

[gsgatlin]

Hello.

I am creating packages for Red Hat type systems. I have a problem on CentOS 6 i686 only. The same package works fine
on i686 and x86_64 fedora 15, 16, and 17 and x86_64 CentOS 6... Its quite odd. My laptop has 8 GB of RAM. It is a lenovo ideapad Y470. The rpms are stored at a yum repository at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/

and

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/

bumblebeed will not stay running. If you reboot and start it by hand it will work for one use. Like:

optirun glxgears

but once you close the glxgears window bumblebeed crashes. It does not do this on a 64 bit OS on the same system.
(E.G. CentOS 6.2 x86_64) On 64 bit everything is working great. I've generated a bumblebee-bugreport-20120512_225151.tar.gz file which I will email.

I have more info which I will add in another section because its very long....

[gsgatlin]

If I run bumblebeed by hand with the --debug flag, I get this output:

http://pastebin.com/kyvGsWii

Notice the part that starts with:
*** stack smashing detected ***

I wonder if I need to use
-fno-stack-protector

on this platform only?

If the red hat "spec file" is useful to help debug this issue I have pasted it to:

http://pastebin.com/0UqAKkG6

Let me know if you need any other info? I don't actually plan on using a 32 bit OS on this box at all but I figured some people might install a 32 bit CentOS 6 for some weird reason.

[Lekensteyn]

Can you compile with `CFLAGS="-g -O0" and paste a new log? Thanks.

[gsgatlin]

Sure. Thanks a lot for looking at this. I pasted the output at:

http://pastebin.com/ZfeSLYps

Looks like its still ending with the same message. *** stack smashing detected ***: /usr/sbin/bumblebeed terminated

[gsgatlin]

Hello. Sorry. I played around with the bumblebee spec file some more. I changed:

make %{?_smp_mflags}
to
make CFLAGS="-g -O0" %{?_smp_mflags}

This seems to have fixed the issue actually. bublebeed no longer seems to be crashing on i686.

http://pastebin.com/mBvJXLQH

So do you think these flags safe to use on all platforms or should this only be changed for centOS 6 i686 systems?

Or maybe there is still some issue that "-g -O0" is hiding? Any ideas appreciated.

[Lekensteyn]

I can't find something that may have caused it, perhaps the compiler is buggy. -O0 disables any optimizations, what about using -O2?

[gsgatlin]

Greetings. I tried:

make %{?_smp_mflags}

which produces a bumblebeed that crashes after one use on i686 centos 6.

make CFLAGS="-g -O2" %{?_smp_mflags}

which works perfectly on i686 centos 6. Quite odd! The Macro %{?_smp_mflags} should default to -j1 I think. It is being built inside a KVM virtual machine with one virtual CPU. Just "make" by itself also crashes after one use.

I believe %{?_smp_mflags} expands to -j[number of CPU's in the system]

I built all of these inside KVM vms because I do not own enough physical hardware to keep around all these systems.

The OS I am building this for is a little bit older because its an "Enterprise OS" so they backport bug fixes and security updates for all the software including gcc. the gcc is version 4.4.6 while in newish fedoras it is newer. Also the kernel is a bit older: gsgatlin@localhost specs]$ uname -a
Linux localhost.localdomain 2.6.32-220.13.1.el6.i686 #1 SMP Tue Apr 17 22:09:08 BST 2012 i686 i686 i386 GNU/Linux

gcc versions in fedora...
fedora 15: 4.6.3
fedora 16: 4.6.3
fedora 17: 4.7.0

In the fedoras I never saw any problems on 32 bit. Just this one OS and arch. Do you think I should add a
conditional in my spec file for stuff older than fedora 15 to use:

make CFLAGS="-g -O2" %{?_smp_mflags}

and then fedora 15 and newer should use:

make %{?_smp_mflags}

Any ideas greatly appreciated.

[Lekensteyn]

Yh, I've looked it up and _smp_flags seems to add a -j flag. I wonder if it's the optimization flag (-Ox) or debugging flag (-g). Since it's likely a compiler issue I suggest you to try different optimization levels (0, 1, 2 or even 3) and see if it helps. If you know assembly a bit, you can also objdump it and diff it.

[gsgatlin]

Hello, Just to follow up, further tests indicate that it doesn't matter which switches are added. Its very strange.

make CFLAGS="-g -O2" %{?_smp_mflags} #works
make CFLAGS="-O2" %{?_smp_mflags} #works
make CFLAGS="-g" %{?_smp_mflags} #works
make CFLAGS="-O3" %{?_smp_mflags} #works
make CFLAGS="-O1" %{?_smp_mflags} #works
make CFLAGS="-O0" %{?_smp_mflags} #works
#make %{?_smp_mflags} #fails
#make #fails

I guess maybe I should add a conditional for this distro and maybe use -O3 ?

[gsgatlin]

Oops. The comments on those last two were a typo. :) They were:

make %{?_smp_mflags} #fails
make #fails

cheers

[Lekensteyn]

I think there is some global CFLAGS var that is being overwritten. Please check the output of configure while compiling using the spec file.

[gsgatlin]

Aha! that makes sense. Well... Quite the line.

CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables'

Let me see if I can narrow down what is actually causing the issue. I'll try one by one to figure it out.

[gsgatlin]

It seems "-fstack-protector" has some effect on this.

make CFLAGS="-fstack-protector" #fails
make CFLAGS="" # works

So perhaps any conditional would need to exclude "-fstack-protector" from the default CFLAGS. But only on
fedoras <=15 and on arch i686 only?

[gsgatlin]

Just for a reference it looks like this spec file:

http://pastebin.com/VimAHTjp

builds with the correct CFLAGS on 32 bit and 64 bit VMs. It takes a few days to properly test however because I
have only one laptop and so I have to re-install with fedoras and RHELs in my spare time at night. So let me know if you think that would be ok or if if there is a bug with bumblebeed and the -fstack-protector CFLAGS that could be fixed?

cheers,

[Lekensteyn]

Probably this bug. I know that there is a place where we use a char array of size 100: https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/switch/sw_bbswitch.c#L40

[gsgatlin]

Thank you for your help with this problem.

I still need to do more tests. But I think I am mostly finished. Here are some URLs to some spec files I made in case I get hit by a car or something before I can write docs and go on IRC and if someone want to pick up where I left off:

bumblebee: http://pastebin.com/wqeZyJ9S
bbswitch: http://pastebin.com/Q8j6xKWn
acpi-handle-hack: http://pastebin.com/zfdK3DPK
acpi-handle-hack-nouveau: http://pastebin.com/Gu2YHJJj
bumblebee-nvidia-32: http://pastebin.com/FJEeT5c1
bumblebee-nvidia-64: http://pastebin.com/qAbF2fJL

I will try to write up some docs and then I'll be in touch on #bumblebee-dev on Freenode. The bumblebee package at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/

and the nvidia drivers at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/

Have been updated. I will work on writing some docs next. I was able to build a pair of VirtualGL rpms on fedora but it was kind of ugly so I need some fedora experts to look at it to see how it could be built with a modern libjpeg-turbo in fedora to make this more acceptable to the community as a submission. (These problems are not there on RHEL 6/ centos 6)

Thanks again.