SaveDialog crash (all games that use it) on Linux

[xsacha]

This only started in maybe the last 24 hours but I get a crash on launching any game that has a save dialog in Linux now.

Backtrace:
(gdb) bt
#0 0x00007ffff5789ce4 in std::thread::join() () from /usr/lib/libstdc++.so.6
#1 0x000000000060c9d8 in PSPSaveDialog::JoinIOThread() ()
#2 0x000000000060ca40 in PSPSaveDialog::Init(int) ()
#3 0x00000000005ce123 in void WrapI_U<&(sceUtilitySavedataInitStart(unsigned int))>() ()
#4 0x0000000000528d77 in CallSyscallWithoutFlags(HLEFunction const*) ()

It also gives an error before it crashes:
57:26:532 CRI FS File E[FileSys]: FileSystems/DirectoryFileSystem.cpp:492 DirectoryFileSystem::OpenFile: FAILED, 2 - access = 1
57:26:532 CRI FS File E[IO]: HLE/sceIo.cpp:1200 ERROR_ERRNO_FILE_NOT_FOUND=sceIoOpen(ms0:/PSP/SAVEDATA/NPJH50679_INST/ALL.DNS, 40004001, 000021a4) - file not found

[unknownbrackets]

If you wrap the join in an if joinable() did it help? Am I using it wrong? I dont want it to stick around.

-[Unknown]

[xsacha]

I tried this:

        if (ioThread && ioThread->joinable()) {
                ioThread->join();
                delete ioThread;
                ioThread = 0;
        }

after just putting it on the join failed. This also fails:

Program received signal SIGSEGV, Segmentation fault.
0x000000000060c9cc in PSPSaveDialog::JoinIOThread() ()
(gdb) bt
#0 0x000000000060c9cc in PSPSaveDialog::JoinIOThread() ()
#1 0x000000000060ca40 in PSPSaveDialog::Init(int) ()
#2 0x00000000005ce123 in void WrapI_U<&(sceUtilitySavedataInitStart(unsigned int))>() ()

So I assume it is joinable if something is happening in that function.

[unknownbrackets]

So, the point of join() is to be an unusable method to trick you into thinking you don't need a condition variable and flag to find out if the thread is done... or something?

-[Unknown]

[unknownbrackets]

Is this relevant?
https://gcc.gnu.org/ml/gcc-help/2009-04/msg00208.html

-[Unknown]

[xsacha]

It appears that StartIOThread() is never run. Makes sense because I just launched the game and haven't seen the dialog yet.
So JoinIOThread will be working with a thread which should be 0. Makes sense because this is in the Init() call.

Is it possible the initialiser isn't being run?

[unknownbrackets]

Constructor sets it to 0... it's static though. Some kind of memory corruption?

-[Unknown]

[xsacha]

int PSPSaveDialog::Init(int paramAddr)
...
    printf("IOTHREAD: %p\n", ioThread);
    JoinIOThread();
...
}

returns:
IOTHREAD: 0x100000001

PSPSaveDialog::PSPSaveDialog()
...
    , ioThread(0)
{
    printf("IOTHREAD: %p\n", ioThread);
...
}

returns:
IOTHREAD: (nil)

Edit: Updated

[unknownbrackets]

Heresy. But don't you need %p in case of 64-bit?

-[Unknown]

[unknownbrackets]

By the way, savedata does work on Android at least.

-[Unknown]

[xsacha]

Might have to do with Android using a custom-made thread implementation in thread.h and not relying on GCC std::thread

It's also working on Symbian and Windows.

Try removing the !defined(ANDROID) from native/thread/thread.h
Android doesn't need to use this custom thread.h anyway.

[unknownbrackets]

Replacing thread.h's contents with #include <thread> and fixing a couple places missing #include <algorithm> and #define NOMINMAX, it still works on Windows and Android.

But, I mean, if ioThread is != 0 that is a big problem. Even a flag and condition var won't get me outta that mess.

-[Unknown]

[xsacha]

Strange one. I don't understand why ioThread's value is changing from nil to 0x100000001 with seemingly no code in between.

I found reference to the number here:
/Core/MIPS/x86/CompFPU.cpp:static const u64 MEMORY_ALIGNED16(ssOneBits[2]) = {0x0000000100000001ULL, 0x0000000100000001ULL};

Maybe something in the JIT is writing to the wrong place. The address of ioThread was 0x15c35b8 when I ran it and base was 0x2300000000.
Although it's just two 32-bit values set to 1, which could be very common.

[unknownbrackets]

Well, does it happen using interpreter?

I mean, as a test, you could try adding some padding members around iothread, see if it changes the situation...

-[Unknown]

[xsacha]

Happens with interpreter.
Side note, I also get an error from the interpreter:
08:21:139 user_main E[CPU]: MIPS/MIPSInt.cpp:409 WARNING : exception-causing add at 08aee82c

[unknownbrackets]

Yeah, that doesn't really matter. What it means is the game used an "add" instruction, rather than "addu". The difference is that "add" trips if it rolls over (afaiu), which we don't support but probably doesn't need to be supported.

-[Unknown]

[xsacha]

Tried rearranging code, adding new variables. It still becomes
IOTHREAD: 0x100000001
Trying debug mode. I'm using GCC 4.9.0

Edit: Works in debug mode

Argh, clean build works! Probably just issue on my side. Sorry about that.

[unknownbrackets]

Gah, I hate those sort of issues.

-[Unknown]