Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mana Khemia crashing A LOT on the latest builds
#1
I've been playing Mana Khemia on pcsx2 svn but it's been crashing VERY frequently on the latest builds (can't point out when it started, sorry). I hope those screenshots help you guys detect the problem.
I've tried playing it with and without speedhacks enabled.

PCSX2 Linux (latest svn), zz-ogl plugin, spu2-x.

Is there anything else I can do to help detecting what's going on?

Thanks in advance!

[Image: screenshot46y.jpg]

[URL=http://img690.imageshack.us/i/screenshot47o.png/][Image: screenshot47o.png][/URL
Athlon II x2 245 (@3.6Ghz), 6gb DDR3 1333, GeForce GTS250 2gb Ram, Linux Mint 12 32bit.
Reply

Sponsored links

#2
Hum it is on my code. There is 2 possibilities
1/ the call of the function (ClutBuffer_to_Array) is bad (wrong parameter) (file ZZoglFlush.cpp.)
2/ The function is bad (file ZZClut.cpp)

You can try to add some message in the middle of the function to understand it. Use the function ZZLog::Error_Log. Mana khemia probably use the 16 bits codepath.

Is the crash random ? Appear in any place ?
Reply
#3
It happens mostly (almost always) during battles. I have error logging already enabled on zzogl, where can I find the log file?

(01-24-2011, 09:56 AM)gregory Wrote: Hum it is on my code. There is 2 possibilities
1/ the call of the function (ClutBuffer_to_Array) is bad (wrong parameter) (file ZZoglFlush.cpp.)
2/ The function is bad (file ZZClut.cpp)

You can try to add some message in the middle of the function to understand it. Use the function ZZLog::Error_Log. Mana khemia probably use the 16 bits codepath.

Is the crash random ? Appear in any place ?

Athlon II x2 245 (@3.6Ghz), 6gb DDR3 1333, GeForce GTS250 2gb Ram, Linux Mint 12 32bit.
Reply
#4
Actually the idea is to add additional logging to understand what it is going on Tongue2 Anyway I will try to debug it.
Reply
#5
I will need your help for testing various versions. The purpose is to find the version that broke.
Can you test version 4112
1/ Ok version 4113.
2/ Ko version 4051.
Thanks.

Edit: can you test a build without sse2, comment -DZEROGS_SSE2 line in plugins/zzogl-pg/opengl/CMakeLists.txt

I have spotted some potential issues but unfortunately it does not fix the crash ...
Reply
#6
I may not be able to perform those testings because I'm on a 64bit system now and I've never tried running a 32-bit chroot before.
Speaking of which, could be the 64bit distro that's causing those issues?

(01-24-2011, 09:17 PM)gregory Wrote: I will need your help for testing various versions. The purpose is to find the version that broke.
Can you test version 4112
1/ Ok version 4113.
2/ Ko version 4051.
Thanks.

Edit: can you test a build without sse2, comment -DZEROGS_SSE2 line in plugins/zzogl-pg/opengl/CMakeLists.txt

I have spotted some potential issues but unfortunately it does not fix the crash ...

Athlon II x2 245 (@3.6Ghz), 6gb DDR3 1333, GeForce GTS250 2gb Ram, Linux Mint 12 32bit.
Reply
#7
Starting a new game, I'm able to get it to crash reasonably often in battles in the Wind Corridor (second assignment). It may take several battles, or happen on the first one. The crashes are happening in the u16 version.

csa was 0, and clutsize was 0x200 when the function was called, but that seems to usually be the case in Mana Khemia on calls to that function. The crash happened on the first iteration of "while (clutsize_right > 0)", on the first call to _mm_store_si128.

Reply
#8
@wingnux do not worry, it was just to accelerate the process. After the debian release, I will try my best to improve the 64 bits support.

I commit my yesterday patch, it probably fix the issue on _mm_store_si128, the array was not 16 bits aligned... It still crash on my system but I do not know why. It is maybe the texture 2d call !

Arcum, how do you tell the debugger to continue when there is a normal segfault in the recompiler ? I used to use this command "handle SIGSEGV nostop" but it is stop for some segfault !


Reply
#9
On my system, r4263 seems to have taken care of the crashes.

And unfortunately, "handle SIGSEGV nostop" is the only command I know for that. I use console logging statements a lot...
Reply




Users browsing this thread: 1 Guest(s)