Pcsx2: Segfaults when run in GDB

[orbea]

PCSX2 version:
pcsx2-2017.02.01_23d081ab2_master-x86_64-1_git

PCSX2 options:
Hacks are disabled.

Description of the issue:
As soon as a game is started when running pcsx2 in GDB it will segfault. Am I doing something wrong and is this even supposed to work? It not, what would be a good way to debug a crash or freeze in a game?

Thread 7 "EE Core" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf119fb40 (LWP 2034)]
0x30052fc8 in ?? ()
(gdb) bt
#0  0x30052fc8 in ?? ()
#1  0x082f2553 in recExecute () at /tmp/SBo/pcsx2/pcsx2/x86/ix86-32/iR5900-32.cpp:716
#2  0x082a3b34 in SysCoreThread::DoCpuExecute (this=<optimized out>, this@entry=0x30052fca) at /tmp/SBo/pcsx2/pcsx2/System/SysCoreThread.cpp:254
#3  0x081827f0 in AppCoreThread::DoCpuExecute (this=0xa6a3190 <CoreThread>) at /tmp/SBo/pcsx2/pcsx2/gui/AppCoreThread.cpp:599
#4  0x082a3b74 in SysCoreThread::ExecuteTaskInThread (this=this@entry=0xa6a3190 <CoreThread>) at /tmp/SBo/pcsx2/pcsx2/System/SysCoreThread.cpp:267
#5  0x081827db in AppCoreThread::ExecuteTaskInThread (this=0xa6a3190 <CoreThread>) at /tmp/SBo/pcsx2/pcsx2/gui/AppCoreThread.cpp:593
#6  0x083ad0c5 in Threading::pxThread::_try_virtual_invoke (this=this@entry=0xa6a3190 <CoreThread>, method=<optimized out>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:543
#7  0x083af1fc in Threading::pxThread::_internal_execute (this=this@entry=0xa6a3190 <CoreThread>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:639
#8  0x083af26e in Threading::pxThread::_internal_callback (itsme=0xa6a3190 <CoreThread>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:680
#9  0xf6953612 in start_thread () from /lib/libpthread.so.0
#10 0xf68ae14e in clone () from /lib/libc.so.6

GDB log - http://pastebin.com/PcHsjALq

How to reproduce the issue:

1. gdb pcsx2
2. Run
3. Start a game.

Last known version to work:
I tried commits back to August of 2016 and did not find any that worked.

PC specifications:
CPU: AMD 6350 FX
GPU: GTX 780Ti
OS: Slackware64-current

[gregory38]

Long story short, yes it is expected. Just disable them in gdb.

handle SIGSEGV noprint 

[orbea]

Thanks, that got me a littler farther... I'm running into a rare freeze while playing arcade in Guilty Gear X2, do you have any better suggestions on how to investigate this?

Thread 8 "MTGS" received signal SIGABRT, Aborted.
[Switching to Thread 0xee8c8b40 (LWP 3755)]
0xf67e31ad in raise () from /lib/libc.so.6
(gdb) bt
#0  0xf67e31ad in raise () from /lib/libc.so.6
#1  0xf67e4ced in abort () from /lib/libc.so.6
#2  0xf67daeb5 in __assert_fail_base () from /lib/libc.so.6
#3  0xf67daf78 in __assert_fail () from /lib/libc.so.6
#4  0xeff65f57 in GSRasterizerList::Queue (this=0xefa3a020, data=...) at /tmp/SBo/pcsx2/plugins/GSdx/GSRasterizer.cpp:1168
#5  0xeff85c27 in GSRendererSW::Queue (this=this@entry=0xefa03780, item=...) at /tmp/SBo/pcsx2/plugins/GSdx/GSRendererSW.cpp:585
#6  0xeff8803d in GSRendererSW::Draw (this=0xefa03780) at /tmp/SBo/pcsx2/plugins/GSdx/GSRendererSW.cpp:538
#7  0xeffb1385 in GSState::FlushPrim (this=this@entry=0xefa03780) at /tmp/SBo/pcsx2/plugins/GSdx/GSState.cpp:1614
#8  0xeffb1588 in GSState::Flush (this=this@entry=0xefa03780) at /tmp/SBo/pcsx2/plugins/GSdx/GSState.cpp:1487
#9  0xeffba240 in GSState::GIFRegHandlerFRAME<0> (this=0xefa03780, r=0xf39566c0) at /tmp/SBo/pcsx2/plugins/GSdx/GSState.cpp:1304
#10 0xeffcc0d8 in GSState::Transfer<3> (this=0xefa03780, mem=0xf39566c0 "\240", mem@entry=0xf39565e0 "\035\200", size=0, size@entry=30) at /tmp/SBo/pcsx2/plugins/GSdx/GSState.cpp:2146
#11 0xefef0c66 in GSgifTransfer (mem=0xf39565e0 "\035\200", size=30) at /tmp/SBo/pcsx2/plugins/GSdx/GS.cpp:717
#12 0x080aa656 in SysMtgsThread::ExecuteTaskInThread (this=0xa6a3300 <mtgsThread>) at /tmp/SBo/pcsx2/pcsx2/MTGS.cpp:409
#13 0x083ad0c5 in Threading::pxThread::_try_virtual_invoke (this=this@entry=0xa6a3300 <mtgsThread>, method=<optimized out>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:543
#14 0x083af1fc in Threading::pxThread::_internal_execute (this=this@entry=0xa6a3300 <mtgsThread>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:639
#15 0x083af26e in Threading::pxThread::_internal_callback (itsme=0xa6a3300 <mtgsThread>) at /tmp/SBo/pcsx2/common/src/Utilities/ThreadTools.cpp:680
#16 0xf6953612 in start_thread () from /lib/libpthread.so.0
#17 0xf68ae14e in clone () from /lib/libc.so.6

GDB log - http://pastebin.com/3GzL6fBx

[gregory38]

I would suggest to try first a build without assertions. Use a "devel" target instead of debug. Actually it depends on what you calll freeze.

That being said it isn't normal that you hit this assertion. Do you know how to use gdb ? Would you be able to print the content of r.top, r.bottom ? Maybe the assertion is wrong, 2048 might be a legal value.

[gregory38]

Hum, it isn't nice, there is an undefined behavior. Do you have an issue with the HW renderer?

[orbea]

I know only the basics in gdb, I'm not entirely sure how to print r.top or r.bottom, but maybe with some pointers I could be more helpful? I'll try a devel target instead of debug.

As for the HW renderer, it seems perfect with Guilty Gear X2 except for an occasional, sudden and unexpected freeze.

[gregory38]

what do you mean by freeze. CPU at 100% ? If you still have PCSX2 open, you can attach gdb to the process when you hit the freeze.

[orbea]

The devel build allows me to start games, thanks.

[orbea]

By freeze I mean the game just suddenly stops on a black screen and then nothing. The issue running it in GDB seems resolved, unless you think anything else should be addressed here this issue can be closed? I'll make a new issue for the freeze next time it happens.

[gregory38]

I need to fix the undefined behavior.

[gregory38]

I fixed the init of the buffer. The assert will still happen but at least behavior will remain correct.

[orbea]

@gregory38 How am I supposed to capture a segfault while in game with gdb? I am experiencing crashes with Midnight Club II when built with -DEGL_API=ON and toggling full screen. However I am not sure how to get in game with GDB and then capture the backtrace. If I use handle SIGSEGV noprint then it fails to capture any crashes and will complain that the program no longer exists after the crash.

[gregory38]

Don't touch the handle. When gdb hit a segmentation fault it will stop. You need to type 'c' to continue. You need to skip the normal SIGSEGV that are in the recompiler. Until you hit the bad one.

The good news is that you should hit fewer normal SIGSEGV on recent build.

I will advise to use a debug build. This way you can see where you are in the backtrace.