segmentation faults & ps3vram swap?

[billb]

When building some applications on YDL 6.2 that are more demanding in terms of memory usage during compiling, I get this sort of error frequently:

../filter/hq2x.cpp: In function 'void HQ4X_16(uint8*, uint32, uint8*, uint32, int, int)':
../filter/hq2x.cpp:11975: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccZMW0da.out file, please attach this to your bugreport.
make[1]: *** [../filter/snes9x_gtk-hq2x.o] Error 1

In that particular case it was with the latest version of snes9x-gtk, but it happens occasionally with other things like sdlmame. Sometimes it will get through OK, so it seems random.

I don't have any particular reason to point at the ps3vram swap as causing this problem, but it seems I never have this problem when I disable ps3vram swap before compiling. If you're experiencing the same problem -- "internal compiler error: Segmentation fault" -- try disabling ps3vram swap before compiling. To do that:

Code: Select all

su -

<root password>

Code: Select all

swapoff /dev/ps3vram

Code: Select all

exit

[billb]

This just happened to me once again today while building RPMs for wxGTK ... internal compiler error. I disable ps3vram swap and start the build process again -- works fine.

[bonedome]

Hmmm
maybe that's why I can't build gnash-0.8.6 (seem to remember something about segmentation faults) I have 0.8.5 which after a few hiccups and a good 3 hours built fine, I'll give that a try later

[uncholowapo]

I actually didn't get the error but I too was also building the latest version of snes9x-gtk when it got stuck on one part of the compile process. Both ps3vram and my swap partition were going crazy so I had to cancel the compilation. I thought that maybe if I had left it overnight it would finish with an error or something but I never found out. Wierd...

[billb]

I actually didn't get the error but I too was also building the latest version of snes9x-gtk when it got stuck on one part of the compile process. Both ps3vram and my swap partition were going crazy so I had to cancel the compilation. I thought that maybe if I had left it overnight it would finish with an error or something but I never found out. Wierd...

Probably around the hq2x filter part? Same thing happens here, but it gets through it eventually. Also, if you're trying to build it on YDL you need a small patch as I mentioned here:

http://code.google.com/p/snes9x-gtk/iss ... d=29&can=1

[uncholowapo]

Wow, didn't know you were fluent in C++. Cool, when I get home I'll try it out. Now about the ps3vram thing, have you tried using a new kernel that has ps3vram as an actual device instead of an mtdblock? Maybe that could be it? I'm just throwing out questions here

[billb]

Wow, didn't know you were fluent in C++.

I wish that was the case, but I just used my Google-fu for that one (get error, search for error, mess with source code, yay it works).

Now about the ps3vram thing, have you tried using a new kernel that has ps3vram as an actual device instead of an mtdblock? Maybe that could be it? I'm just throwing out questions here

No -- have not tried that. I've considered making an updated kernel rpm for YDL 6.2/PS3, though.

[oeboeroe]

seems like a prime candidate for YDL bugzilla?

shame if all this good info just sits on this board only, this is good stuff!

I am intrested in your updated kernels srpm!

thanks again!

[uncholowapo]

Now about the ps3vram thing, have you tried using a new kernel that has ps3vram as an actual device instead of an mtdblock? Maybe that could be it? I'm just throwing out questions here

No -- have not tried that. I've considered making an updated kernel rpm for YDL 6.2/PS3, though.

It's worth a shot. I'd do it but my brother is obsessed with Modern Warfare 2 Another possibility is just the compiler itself just like the error says. What's the version of gcc default in YDL? 4.1 right? Well try compiling it with ppu-gcc43. I think there is a configure option to let you put a prefix infront of gcc, "--exec-prefix" I think.