Can't load games since latest Commit

[mckimiaklopa]

I'm using a GT-I9082 with android 4.2.2 .
Ever since the lastest commit, pcsx-rearmed crashes whenever it loads a game (for the record, all my games are in Pbp)

[dankcushions]

Can we get back trace? some sort of log?

[mckimiaklopa]

Can you give me instructions how to? It seems I can't make alogcat work
with retroarch
On May 26, 2016 7:49 PM, "dankcushions" notifications@github.com wrote:

Can we get back trace? some sort of log?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#43 (comment)

[dankcushions]

I don't know, sorry :(

[RetroD]

I have a log here:
http://pastebin.com/download/UJtGrwjG

[sergiobenrocha2]

@RetroD just post the log here on github...

[luciusbono]

I am not @RetroD, but I came here via this thread and they posted their logs in that forum, so I'm including it in this issue for them.

rearmed_loadgame_crash.txt

[notaz]

Looks like it's @dankcushions and @alexis-puska multitap stuff crashing.

[dankcushions]

seems that way! not sure how to interpret that log. line numbers seem impossible. is there a way of getting a debug build on android? i don't have one these systems :(

[alexis-puska]

hi all,
when i developped the multitap support, i see a bug but i don't fix it. If a controller is set to analog in retroarch but if the physical controler is without analog stick and not configured in retroarch, the library crash in segmentation fault. I will look like it into the code when i have some time, maybe this week or in the next week.
I don't have an android device, it was hard to test to me but i look the problem with the analog/standard pad type.

[RetroD]

@alexis-puska
If you can suggest a work around I can give it a test for you?

I have always used controls with analog sticks.
I have also tried changing the input device from retropad, to w/analog and to none, but I always get a crash

[alexis-puska]

What device are you used ? raspberry pi ?
What is your configuration file, i will try to reproduce the bug and fix it.
Can you put here the retroarch file, psx retroarch files configuration and your pad file configuration ?
Have you activate the multitap support ?

[RetroD]

I have tested it on Nvidia Shield Portable and Shield TV
I just use the default configurations. (Using the nightly from the 25th May)

I tried using the shield portable controller, shield tv controller, and the xbox 360 controller.

I was looking for the multitap option but I can't find it anywhere. Under what menu should it be?

[RetroD]

Also, if you want me to test a core for you, I could do it. I am rooted on the shield portable so if you compiled a new rearmed core I can copy it over and try it for you

[alexis-puska]

can you check in your configuration files if you find theses line :

• pcsx_rearmed_pad3type
• pcsx_rearmed_pad4type},
• pcsx_rearmed_pad5type
• pcsx_rearmed_pad6type
• pcsx_rearmed_pad7type
• pcsx_rearmed_pad8type
• pcsx_rearmed_multitap1
• pcsx_rearmed_multitap2

When i make the multitap support, i don't have add theses line in configuration file, retroarch added this in file at the first launch with the new library. Can you check in your libretro config files.

[RetroD]

Do you mean in the 'retroarch-core-options.cfg' file?

There is only one line for rearmed:
pcsx_rearmed_duping_enable = "on"

I also checked the 'retroarch.cfg' file, but there is nothing with rearmed in it.

Are these the files you mean? It's the only ones that exist. The rest is the gamepad autoconfig files

By the way, the android core revision it says here is r22

[alexis-puska]

it's wird because when you launch retroarch with the pcsx-rearmed core, all configuration missing in the configuration files is automatically created and added in the end of configuration file. In the menu of retroarch -> quick menu did you see the pcsx_rearmed option for set the pad type (standard/analog) multitap option ?

[RetroD]

Quick menu as far as I can tell is only available once you start a game.
But ReArmed for me crashes when I try to start a game, so I don't even get the quick menu :(

[RetroD]

By the way, I used a nightly build and got the core with the updater in retroarch. is that correct or do I need to download the core manually from somewhere?

[mckimiaklopa]

So, does nobody care about fixing this? Isn't arbitrary for users to only download the latest version of each core and not a "stable build"?
.

[dankcushions]

I tried to debug this. When I ran a debug build via gdb i got the same issue we fixed with this hack: https://github.com/libretro/pcsx_rearmed/blob/master/frontend/plugin.c#L71

static long PADreadPort2(PadDataS *pad, int pad_index) {
    /* Temporary hack to avoid segfault when pad_index is a crazy number */
    if (pad_index <= 1 || pad_index > 8) {
        pad_index = 1;
    }

but i got it with PADreadPort1 (a crazy high pad_index caused a segfault). I repeated the fix there, and it works, but then if i enable multitap 1 and also pad 1 to analog mode, i get this crash:

pi@retropie:~/work/pcsx_rearmed $ gdb --args /opt/retropie/emulators/retroarch/bin/retroarch --config /opt/retropie/configs/all/retroarch.cfg --appendconfig /opt/retropie/configs/psx/retroarch.cfg -L /home/pi/work/pcsx_rearmed/libretro.so /home/pi/RetroPie/roms/psx/wipeout.pbp
GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/retropie/emulators/retroarch/bin/retroarch...done.
(gdb) tty /dev/tty1
(gdb) dir /home/pi/work/pcsx_rearmed/
Source directories searched: /home/pi/work/pcsx_rearmed:$cdir:$cwd
(gdb) run
Starting program: /opt/retropie/emulators/retroarch/bin/retroarch --config /opt/retropie/configs/all/retroarch.cfg --appendconfig /opt/retropie/configs/psx/retroarch.cfg -L /home/pi/work/pcsx_rearmed/libretro.so /home/pi/RetroPie/roms/psx/wipeout.pbp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x7667a460 (LWP 1418)]
[New Thread 0x74469460 (LWP 1419)]
[New Thread 0x73828460 (LWP 1420)]
[New Thread 0x72eff460 (LWP 1421)]
[New Thread 0x724ff460 (LWP 1422)]
[New Thread 0x71cff460 (LWP 1423)]
[New Thread 0x714ff460 (LWP 1424)]
[New Thread 0x704fd460 (LWP 1425)]

Program received signal SIGSEGV, Segmentation fault.
0x74809f24 in new_recompile_block (addr=addr@entry=-864022516)
    at libpcsxcore/new_dynarec/new_dynarec.c:8255
8255        opcode[i]=op=source[i]>>26;
(gdb) bt
#0  0x74809f24 in new_recompile_block (addr=addr@entry=-864022516)
    at libpcsxcore/new_dynarec/new_dynarec.c:8255
#1  0x74818d34 in get_addr (vaddr=3430944780) at libpcsxcore/new_dynarec/new_dynarec.c:452
#2  0x748192a8 in jump_vaddr () at libpcsxcore/new_dynarec/linkage_arm.S:383
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

i think we want to properly fix the first issue first, as i think there's some bug that's causing other issues, and those hack fixes are hiding the problem maybe. it shouldn't be crashing in the dynarec!!

[rgascons]

I get a similar issue when I 'fix' the PADreadPort1 like it's done in PADreadPort2.
We may look into https://github.com/libretro/pcsx_rearmed/blob/master/libpcsxcore/plugins.c#L446, as me and @Kekun have found.

[alexis-puska]

in my dev, i change the data structure to stock the keystate of the pad. i thinks the value is cause by the dynarec, it recompile the code in the same time of execution, is the memory allocation for the pad take much space, i don't know if in the dynarec this memory space is fixed. this sources code is very big, complicated and in high level of programmation. i take a look today but i don't thinks that i found were is the bug today... i thinks that i need some help from other dev.

[rgascons]

@alexis-puska what are you having problems with? I've read your latest commits and as far as I can see everything looks fine. Haven't tested the code yet

[alexis-puska]

I don't have a problem with the code i have commit because i used some controller whitout analogique sticks. som poeple on the net have some trouble with analogi sticks and configuration -> segmentation fault. I have found this bug before i start my dev. if we have a doncifuration for retroarch without analogique axis configured, and if we start pcsx_rearmed with analog pad options in the game menu, this may crash. i have made the multitap support for myself becaus i'm a big fan, my girlfriend and my friend of crash team racing, we are frustrated to play only in 2 players on raspberry pi with retropie.
I'm the latest person that made a contribution on this project, since this, some poeple get a segmentation fault, i just will help the other contributor to find and fix this bug. I don't know a lot of the dynarec feature, i only know that recompile in execution the code to optimise memory, code and more.
That can be a idée to look in this class, i d'ont know if the size of memory is hard coding, but it's wired to have a crazy value in integer on the Pad_ReadPort2 callback.
Dankushion help me for debugging, if i have some help to analysing, i take it ^^

[alexis-puska]

Debuging session with @Kekun in Montpellier to suppress the segmentation fault on starting of retroarch.
We suppress in the same time the hack of the crazy value in the source code, @dankcushions :).
Take care to configure correctly your pad with the correct type (analog/standard).

[rgascons]

Hello @alexis-puska, glad to hear you guys fixed the problem!
I am, however, still stucked in the stack smashing detected problem. Looks like some buffer is exceding its predefined size. I wonder why you haven't encountered this problem.

Here's what Valgrind shows: https://paste.gnome.org/pp61i0jqy
And here's another log with the option --leak-check=full enabled: https://paste.gnome.org/pqqi3iqsr

[dankcushions]

tested and works for me! i think this can be closed now :) thanks so much to @alexis-puska and @Kekun!