Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
Issue 214 has been merged into this issue.
Original comment by Jake.Stine
on 16 May 2009 at 7:00
Issue 217 has been merged into this issue.
Original comment by Jake.Stine
on 16 May 2009 at 7:01
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
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:
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
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
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
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
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
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
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
"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
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
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
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
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
Debian stable same error as above.
Original comment by bWo...@gmail.com
on 18 May 2009 at 11:08
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
airmake...@gmail.com
on 13 May 2009 at 10:30Attachments: