are svn bug reports appreciated?

[rohcQaH]

Hi,

I've been following pcsx2 for quite some time, not because I expect to be able to play ps2-games anytime soon, but because I'm curious about the development process.

I'm running gentoo linux 64bit, and since the pcsx2 version in portage is outdated, the easiest way for me to run pcsx2 is to grab everything from svn and compile it.

Does it help you to posts bug/crash reports, or would that get me kicked out as "another svn idiot asking for support"?

If so, what kind of information should a good bug report contain, besides problem description, strace, backtrace, svn-revision, compiler version, plugins/bios/game and - if possible - a patch?


greetings,
rohcQaH

[refraction]

well yes, it would be helpful if the problem was as detailed as possible, mainly what the emulator was doing at the time it crashed by use of looking through logs.

saying "game x is broken, can you fix it" will not be helpful in the slightest.

saying "plugin x works but plugin y doesnt" is mildly helpful as it means there is a problem with plugin x.

anything other than that, its pretty useless information to us ;p

[rohcQaH]

well then, here goes.

this is 64 bit linux with gcc 4.1.2, kernel 2.6.23, glibc 2.6.1, nvidia-cg-toolkit-1.5.0
PCSX2OPTIONS="--enable-sse3 --enable-sse2 --prefix ~/bin/pcsx2" (but disabling sse2/3 didn't change anything)

problem found with svn revision 223 (the first 0.9.4 I tested), confirmed on 227 (current at the time of posting).



started pcsx2 from a fresh config (i.e. all config files removed), configured everything, hit Run->CD. The gfx window pops up, segfault a split-second later.

Originally Posted by strace

[...]
open("<path-to-bios>", O_RDWR) = 22
fstat(22, {st_mode=S_IFREG|0744, st_size=1024, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaba92d000
lseek(22, 0, SEEK_SET) = 0
read(22, "\362\0+\274\376\237\4*\24\354P\260M\177\177Md\32P 2\240\322$#\5\0247#:E0E"..., 704) = 704
read(22, "1$\300< %\0\0\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0\0\0\0\0\0\0\ 0\0\0"..., 4096) = 320
close(22) = 0
munmap(0x2aaaba92d000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Originally Posted by gdb

** (<unknown>:25791): WARNING **: Couldn't find pixmap file: pcsxAbout.bmp
ZeroGS: creating
ZeroGS: Got Doublebuffered Visual!
ZeroGS: glX-Version 1.3
ZeroGS: Depth 24
ZeroGS: you have Direct Rendering!
ZeroGS: Disabling MRT depth writing
ZeroGS: Creating effects
ZeroGS: Creating extra effects
ZeroGS: using accurate shaders
ZeroGS: initialization successful

---Type <return> to continue, or q <return> to quit---
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x000000000051e4f0 in recompileNextInstruction ()
#2 0x000000000051e9ef in recRecompile ()
#3 0x0000000000523980 in Dispatcher ()
#4 0x000000000d025c5b in ?? ()
#5 0x0000000000523931 in Execute_Function ()
#6 0x0000003f8a617f50 in ?? () from /usr/lib/libgobject-2.0.so.0
#7 0x0000000000000000 in ?? ()
(gdb) q

Deactivated Dual Core mode, now it'll sometimes segfault (same backtrace), sometimes just hang with this (but that seems to be a different bug):

Originally Posted by strace

[...]
open("<path-to-iso>.ISO.toc", O_RDONLY) = -1 ENOENT (No such file or directory)
lseek(0, 32768, SEEK_SET) = 32768
read(0, "\1CD001\1\0PLAYSTATION "..., 2048) = 2048
write(9, "CDVD isofile: Image is a DVD.", 31) = 31
write(9, "\r\n", 2) = 2
lseek(0, 32768, SEEK_SET) = 32768
read(0, "\1CD001\1\0PLAYSTATION "..., 2048) = 2048
futex(0x7f83c4, FUTEX_WAKE_OP, 1, 1, 0x7f83c0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_EQ, 0}) = 1
futex(0x7f8400, FUTEX_WAIT, 0, NULLZeroGS: creating
ZeroGS: Got Doublebuffered Visual!
ZeroGS: glX-Version 1.3
ZeroGS: Depth 24
ZeroGS: you have Direct Rendering!
ZeroGS: Disabling MRT depth writing
ZeroGS: Creating effects
ZeroGS: Creating extra effects
ZeroGS: using accurate shaders
ZeroGS: initialization successful
) = 0
futex(0x7f8400, FUTEX_WAIT, 0, NULL <unfinished ...>

I tried to narrow down the problem, changing the following things did not help, it still segfaulted when jumping to 0 in recompileNextInstruction():

- different BIOS versions
- a different game
- setting sound plugin to SP2null
- changing the DVD plugin
- fiddling with the options in zeroGL (there's only one plugin on linux, so I couldn't change it)
- fiddling with the frame limiter
- disabling DC & MTGS
- disabling VU recompilers

When I disabled the EE Recompiler, it started working (who would have guessed?). I reset everything to my previous values with EE Rec disabled, still worked (but slooow).


so yeah, both my tests and the backtrace blame the EE Recompiler. I tried looking at the source (x68/ix86-64/iR5900-64.c) to find the problem, but that's way over my head.


0.9.3 never worked for me when using the recompiler either, but 0.9.3 wasn't supposed to run on 64 bit anyway, so I didn't bother investigating back then.


Of course the problem might just be my system or my system's stupid user, but I'm unable to find the cause either way.
Any useful piece of information I failed to provide?

[coolphoenix]

same for me, ee-recompiler (svn 227) gives a segmentation fault, the window just pops up a second and crashes immediately. so you're not the only one having this problem.

i'm on x86_64 linux too, same kernel.

[shanoah]

Same issue here with x86-64. Revision 230 also doesn't compile because of what appears to be a header that accidentally didn't get changed.

To narrow the issue down further, if you take revision 230, change line 29 of PsxCounters.h to:
extern psxCounter psxCounters[9];

(to match PcxCounters.c), and then change line 44 of x86/iR5900.h to:

#ifdef __x86_64__
#define EE_FPU_REGCACHING 1
#else
#define EE_FPU_REGCACHING 0
#endif

This prevents it from segfaulting on a 64-bit processor. I'm not saying this fixes the issue, partially because I'm sure there's a good reason why they changed that define, and partially because after doing this, Run->Execute seems to hang (You have to choose Run CD or Launch Elf instead).

This is what my own backtrace of the issue showed (after undoing the define change I mentioned):
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x0000000000557a1d in eeFPURecompileCode (xmmcode=0x561e02 <recADDA_S_xmm>, fpucode=0, xmminfo=1216)
at ix86-64/iR5900-64.c:1221
#2 0x0000000000561e4b in recADDA_S () at iFPU.c:1010
#3 0x0000000000560e07 in recCOP1_S () at iFPU.c:323
#4 0x000000000056324d in recCOP1 () at ir5900tables.c:84
#5 0x0000000000559b20 in recompileNextInstruction (delayslot=0) at ix86-64/iR5900-64.c:2149
#6 0x000000000055ac6b in recRecompile (startpc=2147542256) at ix86-64/iR5900-64.c:2639
#7 0x000000000055e2a0 in Dispatcher () at ix86-64/aR5900-64.S:97
#8 0x000000000d02cb04 in ?? ()
#9 0x000000000055e251 in Execute_Function () at ix86-64/aR5900-64.S:59
#10 0x00002ae5289e5f50 in ?? () from /usr/local/lib/libgobject-2.0.so.0
#11 0x0000000000000000 in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y

One thing that seems clear, looking at the code, is that fpucode should not have equaled 0 in eeFPURecompileCode, given that it's called as a function.

In fact, looking through the code, it looks to me like the fpu isn't supposed to be used on a 64 bit processor, since it's only called as NULL on a 64 bit processor, and all the FPU functions aren't defined under x86_64. So perhaps my workaround is the way to go, after all.

Nice seeing the KH1 bug fixed in SVN, btw...

--Shanoah

[NexXxus]

i didn't try 230, but in 223-227 i noticed following things:

- most games, including FFX are about 10-20 fps slower
- Haujobb's Tabula rasa demo gets a speedboost up to 1000fps, na not really, it shows 80-250 fps but the demo plays fast as 1000fps.
Framelimiter doesn't help!
I have a video here: YouTube - Haujobb Tabula rasa : 1000fps in PS2 emulator :P

and i will try 230 soon as possible

[CheatMaster]

I also notice speed decrement in 227.222 is faster than 227 and the current 0.9.4.Also none of my savestares are working in 227 but work on 222

[shanoah]

Shouldn't be too surprising. They just did various timing changes in 223, while fixing various issues (The Kingdom Hearts 1 eye freeze bug, a hang in Shadow Hearts, and I'm sure others).

I'd imagine it'd take a bit of tweaking and optimization before the changes settle down a bit.

and, for reference, you can see the change notes on revisions from here:

SourceForge.net Repository - [pcsx2] Revision 223

[NexXxus]

hhm so why not making a patch in a pnach file for those games to apply the timing fix?
i mean FFX worked fine without it, and now its slower with it.

[rama2]

NexXxus, that's not the point of these fixes.
The counters should be correctly emulated now, while before it was just a hack.

But if you want to you can always try and code a patch system for this

[NexXxus]

i'm trying 230 right now.

hhm i'm not sure, but the music in ffx seems to run faster even when the framelimiter is turned on, and the instrument samples playing a bit "mutilated", what i mean is they sound not complete.
oh and the samples are hanging up, like when you miss or delete the note off in midis and the sample gets in a loop you know?
i compared the song with the PSF2 file i have here.


and yes i changed the line:

extern psxCounter psxCounters[8];
to
extern psxCounter psxCounters[9];

maybe thats the reason, but i need to change it to compile pcsx2 succesfully.

[refraction]

Originally Posted by NexXxus

i'm trying 230 right now.

hhm i'm not sure, but the music in ffx seems to run faster even when the framelimiter is turned on, and the instrument samples playing a bit "mutilated", what i mean is they sound not complete.
oh and the samples are hanging up, like when you miss or delete the note off in midis and the sample gets in a loop you know?
i compared the song with the PSF2 file i have here.


and yes i changed the line:

extern psxCounter psxCounters[8];
to
extern psxCounter psxCounters[9];

maybe thats the reason, but i need to change it to compile pcsx2 succesfully.

hmm check in psxcounters.c for the same line (without the extern) see if thats 8, if not, im a retard

as for the looping, im not sure which bit caused that... probably one of my changes tho, but remember this is a WIP version, there WILL be problems as things change

[NexXxus]

i think its time to report some new bugs as i noticed that its a pcsx2 bug:

this bug happens on all pcsx2 builds i tested since the 0.9.4 release build.
well, like i said, pictures saying more than words: FF12 polygon spikes

and here the savegame, i renamed it to SLES 54354 serial (uk version) and hope it works: savegame