Thread issues ?

[barbudreadmon]

@twinaphex @fr500 I hope you'll be able to help me with this, while i would love seeing this core as a good alternative to emulate saturn games on hardware with low specs, this issue seems out of my league.

speed issue :

On my pentium 2.56Ghz, games that would run at full speed on standalone version will run at around half speed on libretro version.

file_stream_transforms :

When i try to add this code in yabause/src/cdbase.c :
#ifdef __LIBRETRO__
#include "streams/file_stream_transforms.h"
#endif
as it was in the old yabause-libretro repo, i get segfaults, gdb doesn't help with this one.

random segfaults when closing :

The core crashes sometimes when i close retroarch, i didn't find how to reproduce this consistently, and again gdb doesn't say anything helpful.

My guess

It could be related to threads ? To get this core working i stubbed a few functions from yabause/src/thr-linux.c to libretro/thr-unix.c (lines 134-180), perhaps they need some changes to work properly in the libretro core ? The first part of the file, which comes from the current yabause libretro core, seems custom made for the libretro core.
The number of threads for the libretro core doesn't seem to match at all with what is set in yinit.numthreads (also, this value is hardcoded to 4 in the standalone version), at 1 i see 5 threads in top, at 4 i see 12 threads in top, above values don't seem to do much difference.
I also saw there is a rthread.c in the libretro-common repository, is that something that should be implemented when dealing with threads in a libretro core ?

[andres-asm]

no stacktrace?

[barbudreadmon]

@fr500 I managed to fix debug mode (-DINLINE="inline" was causing issues), so now i'm able to get a stack trace for the file_stream_transforms issue.

Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault.
0x00007fffdc6cefa4 in LoadBinCue (cuefilename=0x7fffdd09b740 <full_path> "/roms/rsgun.cue", iso_file=0x555556742310) at ../yabause/src/cdbase.c:613
613 trk[track_num].file_offset = 0;

Looks to me like the issue comes from fscanf being missing from file_stream_transforms

[barbudreadmon]

About the thread issue, i'm getting a lot of YabThreadStart: Thread XX is already started! as soon as i restart the core, so i guess the threads are not closing properly.

[inactive123]

OK, so you require a fscanf implementation for file_stream_transforms?

I imagine that would be hard to implement though in file_streams.c - since it has to go through a VFS interface.

[barbudreadmon]

@twinaphex It seems so

[Alcaro]

Depends on how you define 'hard' I guess

[barbudreadmon]

Thanks, i'll test it after work.

[barbudreadmon]

I'm not getting the segfault anymore, there is an infinite looping though. From fscanf reference :

If a reading error happens or the end-of-file is reached while reading, the proper indicator is set (feof or ferror). And, if either happens before any data could be successfully read, EOF is returned.

It seems to me it is not happening.

[Alcaro]

• Don't pass a va_list to a ...; either #define rfscanf to filestream_scanf and delete the wrapper function, or make filestream_scanf expect a va_list.
• Yes, the EOF handler is probably buggy. To fix, if bufiter == buf+maxlen, skip the filestream_seek.

[barbudreadmon]

Don't pass a va_list to a ...; either #define rfscanf to filestream_scanf and delete the wrapper function, or make filestream_scanf expect a va_list.

Are you sure ? This function feels extremely similar to rfprintf.

Yes, the EOF handler is probably buggy. To fix, if bufiter == buf+maxlen, skip the filestream_seek.

It's still not working (with or without rfscanf), however i could have misunderstood the fix.

[Alcaro]

Yes, it's similar. The difference is rfprintf calls filestream_vprintf, which does take a va_list.

This one looks good to me, but there's a good chance there are non-scanf bugs nearby. Better test it by slapping some printf (or retro_log_cb or whatever) around the scanf calls. I never tested this thing under libretro, I just #defined filestream_tell/etc to ftell/etc and slapped it in a standalone program.

[Alcaro]

It would, of course, be possible to turn filestream_scanf into filestream_vscanf and reintroduce the wrapper function. But I recommend sticking with this #define; the fewer functions take varargs or va_list, the better, they're tricky.