Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tracing segfaults
#1
I've added some code to the GSdx plugin that's causing a segfault.  I was wondering what tools you use to trace this sort of problem.  The assertion dialog has a stack trace, but doesn't provide any function or file names, only addresses.  I've tried plugging the address into addr2line, but it doesn't come up with anything either.  I'd really like to not have to go old school by adding printf's everywhere until I narrow down the problem.  A GDB session doesn't seem to help either, as it doesn't seem to be able to handle the threads properly.
Reply

Sponsored links

#2
May I suggest to install debug symbol. (Or maybe to not strip them)

As a side note, what do you want to do in GSdx ?

With gs dump, it is possible to run GSdx (replay dump) in standalone mode.

Gdb is working properly, I used it since I've worked on this project. However it is a bit tricky to handle SIGSEGV from PCSX2.
Reply
#3
I'm using the build.sh to build.  I've tried using both the --devel and --debug options, and I'm pretty sure that the debug symbols are in there.  See attached for the assertion dialog and the gdb output.

I don't want to get anyone's hopes up, but I'm trying to expand upon your gsdx-ogl-osd branch.  I've updated the original patch to the current head so it compiles, but it's not rendering the text on the screen properly.  I get red streaks in random places each frame.  I'm not sure yet why thats happening as the vertices and texcoords are stable.  Though some of the vertices are negative?  I'm not sure how the m_backbuffer is structured yet, so I need to do some investigation to see how RenderString is supposed to interact with it.

Anyway the assertion doesn't happen in a predictable manner sometimes it will run for several minutes and sometimes only a few seconds.  Which is why I was hoping to use the dump instead of relying on printf statements.


Attached Files Thumbnail(s)
       
Reply
#4
Oh. You need to select the thread of the backtrace.
You can list thread with : info thread
You can select thread with : thread 5 (example put thread number here)
PCSX2 will generate various sigsegv. It is nornal and expected. Skip them or attach gdb only when you hit previous modal. (It will be easier to start).
For gsdx, there is an option to print gl error. I suggest to enable it. An extra gsdx log file (in pwd) will be created. Check severiry eror.

Oh by the way you can still push a branch on github and ping me for help/info/comment.
Reply
#5
Here is what i've got so far, it's pretty much exactly your gsdx-ogl-osd branch just updated for the current master.

https://github.com/JasonBrownDeveloper/p...nderstring

I know if I can get a proof of concept to render the text properly on the screen, I should be able to easily expand it into a complete feature with gettext support and a configurable font with sane defaults per OS. I'd probably try and do some stuff with font pixel alignment too.

The thread command didn't really help as the thread that threw the error is the one with the bad stack trace.
Reply
#6
The above trace is normal. It is due to the virtual memory management of the core. Just use continue to skip it. The booting of a game will generate between 5-50 segmentation fault (on purpose). The real issue ought to be in the mtgs thread.
Reply
#7
By the way, if it is easier for you. You could use shift F8 to generate a gs dump (in snaps directory).

There is a build option to generate the GS dump replayer. Here the code of the replayer
https://github.com/PCSX2/pcsx2/blob/mast...replay.cpp

The easiest way to use it is to use env variable
* GSDUMP_SO will be the .so file
* GSDUMP_CONF will be the path of a directory that contains the GSdx.ini file
Then you can use run the dump with
replay_exe your_gsdump.gs

Note: the replayer support .xz compressed file
Note2: linux_replay option allow to replay the dump several times. (value above 90 will endlessly replay the dump).
Reply
#8
I finally understood what you were saying about PCSX2 generating multiple segfaults.  I didn't realize that it was trapping most of them and I could continue safely within gdb until the trap passes one and raises the gui dialog.  I've fixed the segfault problem, now I just need to get the shader working properly.  Thank you for your help.
Reply
#9
Qapla'

   
Reply
#10
good jobs
Reply




Users browsing this thread: 1 Guest(s)