Linux broken on GCC 4.4.0 as of r1137

[GoogleCodeExporter]

1) Did the game ever work correctly (i.e. not have this problem) on the
Official PCSX2 build or an earlier version of PCSX2 playground?
(If so, please specify the latest pcsx2-playground or Official revision
that last worked.)

The last revision I've tried that worked was 1130.

2) What steps will reproduce the problem?

Try to boot up FF XII (EU) or FF X (EU). FF XII crashes with many error
messages before seeing anything. FF X gets the exact same error messages,
but it crashes a while later, notably after loading a save game and trying
to go into 3D.

3) What exactly happens when you experience this issue (listing any console
errors or screen output you recieve)?

Eg. Alot of SPU2async messages occur, and the games crash eventually.

4) What version of PCSX2 are you using? On what operating system?
Latest revisions of PCSX2 (cur. 1173), Arch Linux i686

5) Please provide any additional information below.
These errors do occur in at least these two games. I've tried with many
different speed hack combos. Turning them off/on, etc. It seems to be a
regression of some sort. I've tried different sound plugins, and also
turning it off. I have tried the same revisions in Windows, and there's no
issue whatsoever there. I've also noted that the newer revisions that don't
work include the ZeroPad 0.3.0 rather than 0.2.0.

Original issue reported on code.google.com by airmake...@gmail.com on 13 May 2009 at 10:30

Attachments:

• bug.txt

[GoogleCodeExporter]

Same SPU2async errors occur to me you probably reporting same bug, watch a bit 
higher
in issues :)

Original comment by bWo...@gmail.com on 14 May 2009 at 1:19

[GoogleCodeExporter]

Not really. SPU2sync lines have been spamming all games, until cottonvibes 
commented
it out. (And I'm unable to reproduce this on FFXII(US), btw...)

Original comment by arcum42@gmail.com on 14 May 2009 at 9:38

[GoogleCodeExporter]

Yeah, it looks like the same bug with a different wording :p I also compile 
pcsx2 in
a 32 bit chroot (x86_64 Arch normally)!

Original comment by airmake...@gmail.com on 16 May 2009 at 1:35

[GoogleCodeExporter]

I think I found the sinner. rev. 1137. ASM commit. Rev. 1136 is the latest rev 
that
works for me.

Original comment by airmake...@gmail.com on 16 May 2009 at 2:13

[GoogleCodeExporter]

Ok we've been getting a lot of varying reports of bugs related to 1137.  This 
is what I 
know so far:

* Behavior is specific to Linux.  Windows version of pcsx2 has *no* problems.

* Behavior varies from user to user [perhaps distro/kernel related].  Some 
users have few 
or no problems, others have constant freezes, and others have occasional 
crashes on 
specific games.

* The revision in question made changes to the VTLB, which involves the Memory 
Protection 
/ Exception handler, which is the most likely code for having varying behavior 
patterns 
between kernels or distros.

I'm going to merge several older/related issues into this one.

Original comment by Jake.Stine on 16 May 2009 at 6:59

• Changed title: Linux broken as of r1137
• Changed state: Accepted
• Added labels: Component-Core, OpSys-Linux, Priority-High, Type-Regression
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Issue 214 has been merged into this issue.

Original comment by Jake.Stine on 16 May 2009 at 7:00

[GoogleCodeExporter]

Issue 217 has been merged into this issue.

Original comment by Jake.Stine on 16 May 2009 at 7:01

[GoogleCodeExporter]

1206 and subsequent versions of Pcsx2 *may* very likely fix this problem now.  
Please 
update and test, and provide feedback here.  Thanks.

Original comment by Jake.Stine on 17 May 2009 at 1:04

[GoogleCodeExporter]

Here is 1206 log simply run execute after about 15 seconds of video crashes.

Original comment by bWo...@gmail.com on 17 May 2009 at 1:53

Attachments:

• emuLog.txt.tar.gz

[GoogleCodeExporter]

Ok that crash is very clearly being caused by the protected memory handler.  
But does 
it persist in all newer SVNs as well (including ones where we removed logging 
facilities from the exception handler?)

Original comment by Jake.Stine on 17 May 2009 at 2:04

[GoogleCodeExporter]

1212 simply execute as well 
# Restart Without Memory Clear Done.
Offset 0xea000000 invalid. Legit SIGSEGV. Aborting.
Segmentation fault

It crashes about same time as 1206 when should start loading game or something 
like
that after Playstation 2 "header" or what that word is sry for english...

Or when try run cd

ZeroGS: Disabling MRT depth writing
CDGetToc Param[0]=0, Param[1]=1
Offset 0xea000000 invalid. Legit SIGSEGV. Aborting.
Segmentation fault

I think you should wait for other linux ppl log coz i somehow suspicious about 
mine
builds none of them work correctly and i cant build it in 64bit system (now 
schroot)
because of libgthread-2.0.so problems 

Original comment by bWo...@gmail.com on 17 May 2009 at 2:17

[GoogleCodeExporter]

I find it very strange that everyone who has reported this issue, are building 
in a
chroot.

Original comment by airmake...@gmail.com on 17 May 2009 at 3:59

[GoogleCodeExporter]

Indeed.  New theory: if you need -m32 to build pcsx2, then chances are it's not 
going to 
be a stable build.  It's possible there are specific dependencies on the chroot 
causing 
problems, but hell if I know how to track that kind of stuff down.

Actually, I'd like to know if anyone's managed to compile with -m32 [ie in an 
environment where it's required], and obtain a working build as a result.

Original comment by Jake.Stine on 17 May 2009 at 4:20

[GoogleCodeExporter]

I m trying compile pcsx2 on debian lenny 64bit, i have almost all needed 
librarys in
/emul folder. But now i m facing

/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libgthread-2.0.so when searching 
for
-lgthread-2.0

such problem i tried this libglib2.0-dev then i get hundrids of lines something 
like that

CDVD.cppSad.text+0x1f92): undefined reference to `std::basic_string<char,
std::char_traits<char>, std::allocator<char> 
>::_Rep::_M_destroy(std::allocator<char> c
onst&)'
CDVD.cppSad.text+0x1fa1): undefined reference to `std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::~basic_string()'
CdRom.cppSad.text+0x25): undefined reference to `std::ios_base::Init::~Init()'
../CDVD/libps2_cdvd.a(CdRom.o)Sad.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
make[1]: *** [pcsx2] Error 1

and it fails

Original comment by bWo...@gmail.com on 17 May 2009 at 4:25

[GoogleCodeExporter]

Hmm, that may indeed be a problem, Jake. I'll try building pcsx2, and remove the
"-m32" part since I already build for 32-bit anyways in the chroot. I mean, the
revisions compile without any hick-ups at least. Also, I always build the pcsx2
packages with fakeroot (abs in archlinux), which has given me some strange 
problems
with mplayer before.

Original comment by airmake...@gmail.com on 17 May 2009 at 4:42

[GoogleCodeExporter]

Third theory:  There could be problems anywhere type 'long' is used in pcsx2 
code or 
plugin code.  Apparently GCC compiles longs as 64 bits even with -m32 
specified, and 
some of the code in pcsx2 may assume 'long' is a 32 bit value.

Original comment by Jake.Stine on 17 May 2009 at 6:24

[GoogleCodeExporter]

"undefined reference to`__gxx_personality_v0"? Hmmm... Do you have g++ 
installed? Why
Debian and Ubuntu even separate gcc and g++, I don't know, but that's the type 
of
error you'd usually get if compiling a C++ program on a C compiler.

__gxx_personality_v0 is a symbol from the standard C++ library, and should be
recognised as long as the compiler knows about C++.

Original comment by arcum42@gmail.com on 17 May 2009 at 8:48

[GoogleCodeExporter]

And just to mention; I'm still compiling in a 32 bit chroot, and running pcsx2 
there.
Being able to compile outside of the 32 bit chroot with -m32 was recently added 
and
is experimental.

But the -m32 flag shouldn't have an effect if you are compiling in a 32 bit 
environment.

Original comment by arcum42@gmail.com on 17 May 2009 at 8:53

[GoogleCodeExporter]

Maybe it's a distro spesific issue on my side :'S What distro and
glibc/gcc/kernel-versions are you using? It's Archlinux 2.6.29.3 vanilla, glibc 
2.9,
gcc 4.4.0 here.

Original comment by airmake...@gmail.com on 18 May 2009 at 9:34

[GoogleCodeExporter]

I'm using Gentoo (or Funtoo now, really[1]). Outside of the chroot, I'm using 
glibc
2.9, gcc 4.3.2, kernel 2.6.28 (with zen patchset).

Inside the chroot, glibc 2.9, gcc 4.3.3. I haven't been patient enough to 
update to
4.4.0 yet, given how long gcc takes to compile. And I've been meaning to update 
my
kernel.

And as of r1214, I've successfully compiled and ran pcsx2 both in and out of 
the chroot. 

And, you know, I kind of like Arch. I'd probably be using it if I hadn't already
discovered Gentoo. I tried it on my eeePc for a bit...

[1] Basically Gentoo, but with a fork of the repository that's kept in sync 
with the
Gentoo repository, but with improvements.

Original comment by arcum42@gmail.com on 18 May 2009 at 9:51

• Changed title: Linux broken on some systems as of r1137
• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

Hmm ... I still just get the: 
Offset 0xea000001 invalid. Legit SIGSEGV. Aborting.
Segmentation fault

:\ But you're using gcc 4.3.3. I'll try getting that up running :)

Original comment by airmake...@gmail.com on 18 May 2009 at 11:05

[GoogleCodeExporter]

Debian stable same error as above. 

Original comment by bWo...@gmail.com on 18 May 2009 at 11:08

[GoogleCodeExporter]

Ye, I found another error. Have you noticed that after pcsx2 crashes, repeating 
keys
on keyboard doesn't work at all? :S I have to go into the gnome keyboard 
options and
change repeat speed; then it works again. This makes even less sense :p

And also, there is some change:

FF XII (EU): Simply crashes with the error message above.
FF X (EU): It boots up, but when loading a save file, it just hangs with a black
screen. No error message or anything.

Original comment by airmake...@gmail.com on 18 May 2009 at 11:21

[GoogleCodeExporter]

Yeah same for me it is very annoying, but i use kde3.5 anyway kde4 sux :) 

Original comment by bWo...@gmail.com on 18 May 2009 at 11:25

[GoogleCodeExporter]

The keyboard issues odd. I'll have to look at that.

And I messed up my Kde 3.5 install when installing Kde 4, and decided to switch 
to
Xfce 4.6.1 for a while. I switch desktop environments every so often anyways, 
and
Xfce's reasonably comfortable. At a moments notice, I can load up IceWM(great 
for
anything processor-intensive), Kde 4.2 (since I didn't get around to 
uninstalling
it), possibly Gnome (though it might have broken; don't recall), and I used to 
have
E17 in there. (Got tired of worrying about running a desktop environment from 
svn)

And I've got the opening to FF XII(US) running in the background. Though I 
suppose I
should switch microVU off if I'm testing Linux. :)

Original comment by arcum42@gmail.com on 18 May 2009 at 11:45

[GoogleCodeExporter]

I'm really confused on the 0xea000000 address thing.  There's nothing in pcsx2 
that 
should be consistently pulling that address out of a hat.  It's not a valid 
MIPS 
address and it's not a valid pcsx2 memory or recompiler address.  I'd love to 
know 
where that address is actually coming from.

Is it possible to get a stack trace on where the Legit SIGSEGV is coming from, 
like 
what code is causing it?

Original comment by Jake.Stine on 18 May 2009 at 4:23

[GoogleCodeExporter]

I could run a stack trace ... If I knew how to do one :p

Original comment by airmake...@gmail.com on 18 May 2009 at 4:46

[GoogleCodeExporter]

Hmm ... Actually, I managed to run r1221 just fine when I compiled it with gcc 
4.3.3. :s

Original comment by airmake...@gmail.com on 18 May 2009 at 5:08

[GoogleCodeExporter]

Lovely. So it sounds like a gcc 4.4.0 issue. I suppose I'd better unmask it 
(since
it's masked for testing in gentoo), and install it...

Original comment by arcum42@gmail.com on 18 May 2009 at 7:31

[GoogleCodeExporter]

Ye :) But it still doesn't explain why bWolas has the same issue. He has debian
stable, which apparently uses 4.3.2 http://packages.debian.org/lenny/gcc

Original comment by airmake...@gmail.com on 18 May 2009 at 7:43

[GoogleCodeExporter]

Right, but he wasn't getting the same issue. He was getting the "undefined 
reference
to`__gxx_personality_v0" error when compiling. Which is a symbol in the 
standard C++
library, and should be there regardless.

I seem to recall getting that error when experimenting in Virtualbox with 
Ubuntu,
when I didn't realize that gcc had been installed, but g++ hadn't.

Original comment by arcum42@gmail.com on 18 May 2009 at 8:28

[GoogleCodeExporter]

At a guess, he may need to do:
sudo aptitude install build-essential

Original comment by arcum42@gmail.com on 18 May 2009 at 8:31

[GoogleCodeExporter]

I'm referring to Comment 22 :p It looks like he got it compiled at least.

Original comment by airmake...@gmail.com on 18 May 2009 at 9:17

[GoogleCodeExporter]

Oh, I figured he meant that he got the same error as he had above in comment 14.
Unfortunately, when you are on comment 22, same as above is very ambiguous. :)

And I'm compiling with gcc 4.4.0 right now, though if it crashes, I probably 
won't
have time to deal with it till later; I'm getting ready for work right now...

Original comment by arcum42@gmail.com on 18 May 2009 at 9:21

[GoogleCodeExporter]

Confirmed. Got the same error after building in 4.4.0. (Also realised that I 
forgot
to enable graphite. May have to rebuild for that one, because it's supposed to 
be
nice...)

Original comment by arcum42@gmail.com on 18 May 2009 at 9:35

• Changed title: Linux broken on GCC 4.4.0 as of r1137

[GoogleCodeExporter]

It's a bug in optimization, btw. If you add --disable-optimization to your
PCSX2OPTIONS in build.sh, it works. (But it's not optimised, so it'll be 
slower.)

That's actually a new configurization option as of r1210, btw...

Original comment by arcum42@gmail.com on 18 May 2009 at 9:44

[GoogleCodeExporter]

You might try r1222. It's going to look ugly when you compile it, 
unfortunately...

Original comment by arcum42@gmail.com on 19 May 2009 at 1:51

[GoogleCodeExporter]

Marked as 'done' since it's not really "fixed" per se, and wasn't a coding task 
in 
the end.  A more correct fix may be uncovered at a later date.

Original comment by Jake.Stine on 20 May 2009 at 3:06

• Changed state: Done
• Added labels: Type-Other
• Removed labels: Type-Regression